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The  DucposG  of  this  reoort  is  to  give  an  overvie.v  of  the  Soft.vare 
Design  and  Verification  Systeni  (SDVS)  and  present  the  design  and  inipleinentation 
tecnniques  used  to  develoo  SUVS.  The  SDVS  has  been  developed  as  an  integrated 
collection  of  software  tools  in  support  of  the  AFAL  Digital  Avionics  Information 
System  (DAIS)  program.  DAIS  is  an  infonnation  management  system  approach 
to  avionics  processing  applications.  The  overall  objectives  of  DAIS  and  SDVS 
are  presented  in  section  two. 

Section  three  describes  the  DAIS  facility  being  developed  at  AFAL. 

Included  is  a discussion  of  the  information  management  system  core  elements 
and  the  overall  system  architecture.  The  DAIS  support  facility  which  will  be 
used  to  evaluate  the  real-time  operation  of  the  DAIS  core  elements  is  also 
described. 

The  DAIS  mission  software  will  be  developed  us^ng  the  SDVS  tools  discussed 
in  section  four.  Each  of  the  seven  SDVS  modes  of  operation  associated  with 
the  configuration  management,  simulation  and  testing  of  mission  software  is 
presented.  The  SDVS  high  level  languages  for  defining  simulated  DAIS  mission 
scenarios  and  orocessing  siniulation  data  are  described  with  illustrative 
examples.  Section  four  concludes  with  a description  of  the  simulation  functions 
available  in  SDVS. 

Section  five  presents  the  techniques  and  tools  employed  by  TRW  in 
designing  and  building  the  SDVS.  The  basic  design  philosophy  was  based  on 
a top-down  design,  development,  and  testing  approach.  Topics  concerning 

structured  prooramminq  techniques,  programming  standards,  test 
planning  and  configuration  control,  rehostabi 1 i ty  of  SDVS,  definition  of 
control  and  data  interfaces,  etc.  are  also  presented.  Section  five  continues 
with  a discussion  of  the  overall  program  plan,  the  development  of  SDVS  in  a 
three  phase  effort,  and  concludes  with  some  quantitative  data  concerning  the 
productivity  achieved  using  the  various  development  techniques.  Conclusions 
and  recommendations  are  outlines  in  section  6. 
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The  purnose  ot  the  Dipital  Avionics  Information  System  (DAIS) 
project  is  to  demonstrate  a coherent  solution  to  the  problem  of  pro- 
liferation and  nonstandardization  of  aircraft  avionics,  to  develop  and 
test  in  a "hot  bench"  configuration  (known  as  the  Integrated  Test  Bed  - 
ITB)  the  DAIS  concept,  and  to  permit  the  Air  Force  to  assiime  the  initia- 
tive in  the  sneci fication  of  avionics  configurations  for  future  Air  Force 
w(>anon  systems  acquisitions. 

Historically  mission  information  requirements  have  been  established 
alonn  semi -autonomous  subsystem  areas  such  as  navigation,  weapon  delivery, 
stores  management,  flight  controls,  communications,  etc.  Within  each  of 
these  functional  areas  the  trend  has  been  tavard  digital  systems  each  with 
its  ov/n  unique  processing,  transfer  and  display  of  information.  There  has 
been  an  integration  of  requirements  between  functional  areas  only  as 
necessary  for  interaction  purposes.  The  DAIS  concept  proposes  that  the 
processing,  multiplex  and  display  functions  be  common  and  service  all  the 
previously  described  areas  or  subfunctions  on  an  integrated  basis.  When 
counled  with  other  existing  programs  and  facilities,  the  DAIS  "hot  bench" 
will  contain  the  flexibility  to  evaluate  a spectrum  of  multiplex,  process- 
ing and  display  approaches  such  that  decisions  regarding  interface  standards, 
processing  archi tectures , display  concents,  etc.,  can  be  made.  As  technology 
becomes  available  and  the  "hot  bench"  is  programmed  to  solve  desired  aircraft 
avionic  problems,  the  built-in  flexibility  will  accept  adaptation.  In  this 
manner,  an  evolutionary  grov;th  will  continually  update  the  "hot  bench"  con- 
figuration whenever  the  capability  or  need  exists. 

The  DAIS  design  approach  reflects  a total  system  concept  which  is 
functionally  oriented  rather  than  hardv^are  oriented.  For  example,  a 
"navigation  subsystem"  in  DAIS  does  not  refer  to  a set  of  black  boxes 
winch  are  identifiable  functions  v/hich  are  performed  various  places 
throughout  the  system,  flot  that  the  system  is  not  dedicated  exclusively 
to  doing  the  navigation  function  alone;  it  is  also  used  to  perform  the 
functions  of  many  other  "subsystems".  DAIS  will  certify  ideas  and  classes 
of  equipment  that  can  satisfy  weapon  system  needs. 


? 


Sneci'fic  obioctivos  of  tho  DAIS  proorrii’i  incliide: 


a.  Develop  an  AFSC  in-house  capability  to  define,  denonstrate, 
test,  and  evaluate  evolutionary  changes  and  requirenents  in 
digital  avionics. 

b.  Define  and  design  a "hot  bench"  configuration  for  a limited 
hard\;are  demonstration  with  growth  potential  to  accommodate 
a large  class  of  weapon  systems. 

c.  Identify  and  recommend  standards,  criteria,  and  specifications 
which  must  be  instituted  to  reduce  the  pro! i feration  and 
complexity  of  avionics  svsteris. 

d.  Provide  means  for  quantitatively  evaluating  cost  (both 
acquisition  and  life  cycle)  aspects  and  for  exploiting 
potential  increases  in  reliability,  maintainability,  and 
versatility  of  future  weapon  systems. 

e.  Influence  the  design  and  (ievelopment  of  sensors  via  input- 
outnut  format  specifications  vihich  viill  allow  the  new  sensors 
to  be  compatible  with  the  DAIS  concept  and  ensure  optifial 
information  transfer  and  management. 

f.  Identification  of  many  diverse  programs,  offices,  etc.,  involved 
in  digital  avionics  with  the  resulting  integration  of  their 
requirements  and  actions  into  one  coherent  program. 


The  DAIS  software  hierarchy  necessar.v  to  support  these  goals  is  depicted 
in  Figure  1.  The  mission  software  represents  the  Operational  Flight  Program 
(OFP)  for  a particular  DAIS  simulated  mission.  The  support  software  includes 
all  the  necessary  non  real-time  software  tools  to  aid  in  the  development, 
testing,  verification,  and  maintenance  of  the  mission  software.  These  tools 
include  configuration  management  aids,  functional  and  bit  level  simulations 
of  the  DAIS  "hot  bench",  and  user  interface  languages.  They  are  known  collective! 
as  the  Software  Design  and  Verification  System  (SDVS).  In  addition  to  the 
SDVS,  the  DAIS  support  software  includes  the  Integrated  Test  Bed  (ITB)  Support 
Software  for  real-time  control  and  monitoring  of  the  DAIS  "hot  bench". 
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SECTION  III 


gVERV I EW  OF_  THE.  DAIS  I MTEGRATED  TEST  BED 

Ttie  DAIS  "hot  bonch",  or  Intoqrotod  Tost  Bed  (ITD)  is  an  inforr.tition 
manaqonent  systen  consistinq  of  a set  of  federated  processors  interfaced 
to  each  other,  to  avionic  sensors,  and  to  control  and  displays  by  a 
MIL-STD- 1553A  nultiplex  data  hi/s;  and  a supoort  facility  to  perforn  the 
information  nanaqeiient  systen  monitor  and  control  fonctions.  Einure  3-1  is 
a simplified  block  diaqran  of  the  DAIS  Inteqrated  Test  Bed.  Control  of 
information  nanagenent  systen  functions  is  porfon"ed  by  the  DAIS  rrission 
software  which  is  partitioned  among  the  DAIS  processors. 

The  followinq  paraqraphs  highlight  the  functions  of  the  various  Integrated 
Test  Bed  components. 

1 . D_A  J n f ormati  on  liana 'J ej«o p_t  Sy_s  tejii 

The  DAIS  core  elements  shown  in  Einure  2 are  based  on  a federated 
processor  arch i tecture.  Each  DAIS  processor  is  connected  to  a Bus  Control 
Interface  Unit  (BCIU)  which  initiates  data  transmission  over  a redundant 
nultiplex  bus  system  between  the  processors  and  remote  terminals  (RT).  The 
latter  being  the  interface  between  the  data  bus  and  the  simulated  avionic 
equipment.  Each  BCIU  is  actually  an  intelligent  I/O  channel  which  executes 
I/O  commands  stored  in  the  DAIS  processor's  memory.  Centralized  single 
point  data  bus  protocol  is  performed  by  a processor  resident  software  execu- 
tive and  a selected  master  BCIU. 

The  remote  terminals  provide  an  interface  between  the  bus  and  aircraft 
equipments.  Conceptional ly , it  functions  similar  to  a BCIU  by  transferring 
data  to  or  from  the  equipment  to  v;hich  it  interfaces.  The  UT  contains  inter- 
face nodules  v/hich  can  be  interchanged  to  provide  the  correct  electrical 
interface  for  different  oguipment.  It  can  also  be  programmed  to  define  the 
mapping  of  data  between  the  bus  and  the  aircraft  equipments. 

The  mission  software  is  distributed  among  the  set  of  processors  in  the 
system.  It  consists  of  application  software,  which  performs  the  processina 
required  for  a specific  ai rcraft/mission  application,  and  the  executive 
software,  which  performs  system  control  and  provides  services  to  the 
application  software. 
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SUPPORT  FACILITY  DAIS 


Figure  2.  Simplified  Block.  Diagram  of  ITB  Facility 


The  executive  software  is  furthr;r  divided  it)to  the  naster  executive, 
and  the  local  execiitive.  The  master  executive,  which  is  responsible  for 
system  control,  resides  in  one  processor  desipnated  the  master  processor. 

The  monitor  executive  resides  in  the  monitor  processor,  and  it  orovides 
a backup  to  the  naster  executive.  In  the  event  of  master  processor/mas- 
ter BCIl)  failure,  the  monitor  executive  will  assume  system  control.  A 
cony  of  the  local  executive  is  located  in  each  processor  and  provides 
real-time  services,  includino  data  read  and  write,  task  control,  etc.,  to 
the  annlication  software. 

The  mission  software  will  bo  implemented  in  the  JOVIAl.  J73/I  hinher 
order  lanquaoe  utili;'inn  structured  pronramninn  techniques,  and  a nxidular 
arcliitecturo  approach. 

2 DAIS  Support  Facility 

The  Support  Facility  will  provide  the  necessary  interfaces  to  set 
up,  provide  real-time  control  and  monitoring  functions,  and  collect  data 
for  post  run  analysis  for  all  DAIS  testinq  activities. 

A DECIO  computer  will  be  used  to  execute  real-time  aircraft  and 
environment  models,  compile  (in  J73)  the  DAIS  executive  and  applications 
software,  generate  simulated  mission  scenarios,  perform  post  run  analysis, 
and  maintain  all  the  above  files  and  simulation  data  under  a confinuration 
management  system. 

The  Performance  Monitoring  and  Control  (PMC)  computer  in  Figure  3-1 
is  a PDP  11/40  interfaced  with  the  DECIO  via  a DMA  windov/.  This  machine 
will  be  used  to  load  the  mission  software  from  DECIO  storage  onto  the  DAIS 
Processors.  Operation  of  each  processor  will  be  monitored  by  a Super 
Control  and  Display  Unit  (SCADU)  and  a Console  Interface  Unit  (CIU)  which 
monitor  the  processor's  memory  bus  and  perfonn  suclt  functions  as  monitoring 
specified  memory  addresses,  tracing  branch  instructions,  breaknointing  based 
on  events,  etc.  The  PMC  computer  will  interact  with  the  user  to  set  up 
SCADU  monitoring  parameters  and  can  also  use  canned  scenarios  stored  on  the 
Di;C10  to  set  un  the  SCADU,  Real  time  display  of  system  performance  will  be 
available  on  a local  CRT. 
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The  Sinulated  S'ltisystpns  Data  Fornattinq  (SSDF)  computer  controls 
the  transfer  of  data  betv/een  the  simulation  models  executinq  on  the  HECIO 
and  the  DAIS  mission  softv/are  via  the  multiplex  system.  It  obtains  data 
from  the  simulation  models  needed  to  drive  the  backup  cockpit  instruments 
and  suonlies  it  to  the  cockpit  interface  and  the  Video  Control  Center 
(VCC).  The  SSrif  also  nrovides  a mass  memory  simulation.  Durinq  real-time 
testinn,  the  VCC  receives  th^^  simulated  aircraft's  position,  altitude,  and 
attitude  data  from  the  simulation  models.  These  parameters  are  used,  alom 
wi  til  the  necessary  display  man  information,  to  provide  the  simulated 
external  scene  display.  Other  VCC  functions  are  the  diqital  recordinq  of 
the  backup  cockoit  instrument  data  and  the  video  recordinq  of  DAIS  controls 
and  displays  data. 


4. 


Df'scrintion  of  the  S[)VS 


Soctinn  3 doscrihod  tho  HAIS  concept  'ind  nresonted  th'’*  h^irdv/riro 
cnn^i  pura  ti  on  for  th'^  Intenratod  Tost  f!or|  Facility.  This  section 
describes  the  SPVS  which  consists  of  an  intoqrated  collection  of  soft- 
ware tools  to  aid  in  the  developnent,  codinn  and  testinn  of  the  actual 
flinht  so<"tware  for  the  DAIS  nrocessors.  Throuoh  the  SDVS , an  applica- 
tions nrooranner  wi 1 1 have  such  capabilities  as  the  automated  control  of 
sofcv.'are  versions  and  chanqes,  an  all-dinital  simulation  capability  for 
executina  and  testino  the  DAIS  Mission  Software  without  use  of  the  actual 
hardware,  the  automatic  control  of  simulation  runs  and  the  editinn  and 
analysis  of  the  test-data  qenerated,  etc.  SDVS  will  be  used  bv  both  Air 
Force  and  other  contract's  personnel  to  aid  in  the  desiqn,  impleiientation 
and  testinn  of  all  Mission  Software  for  the  DAIS  hot-bench.  The  SDVS 
tools  essentially  automate  much  of  the  manual  setuo  and  housekeeninn 
activities  nreviousl/  required  for  software  development  in  an  inteqrated 
user  oriented  facility. 

The  followinq  naranranhs  summarize  the  basic  functions  the  SDVS 
provides  users.  Each  of  the  basic  operation  modes  will  bo  discussed  in 
addition  to  the  SDVS  proqramninq  lanquanes  for  defining  simulated  DAIS 
scenarios  and  for  editing  and  disnlayinq  simulation  data. 

1.  SDVS  'iodes  of  Operation 
■1.  Mode  Selection 

IJnon  entering  the  SDVS,  (by  performing  an  "R  SDVS")  the  user  is  proniptc  . 
for  the  desired  node  of  operation.  The  follov/ing  scenario  illustrates  a 
user  entering  SDVS  and  requesting  (via  the  "HFl.P"  command)  a display  of  the 
nodes  of  operation. 


R snvs 


uf  Lcnnr  in  snvs  vf.r.  iR(06ii/f,) . your  'iamf 

(inns  rjAfirs  114370  Assioocn  to  this  snvs  rdh) 

snvs  IS  REAnv.  llillCH  mode  of  OPERATinri  is  oesireo? 
++>IIELP 

PLEASE  EOTEP  ’lAME  01  INITIALS  OF  OflE  OF  FOLLO'IINr.; 


FILE  OFNEPATION  (FO) 

SET  IIP  K RUN  SIMULATION  (SIJRS) 

POST  RUN  EOIT  (PRE) 

ROLLBACK  (Rtl) 

OELETF  MOnr.  (MANAGER  ONLY)  (OM) 

SUPERVISOR  MORE  (MANAGER  ONLY)  (SM) 
LOGOFF  (LOG) 


Btispd  on  the  user's  innut,  SnVS  will  enter  the  selected  node  of 
operation  and  nerforn  the  desired  user  actions.  Uhenever  the  user  is 
finished  in  SnVS,  he  enters  the  LOGOFF  connand.  The  follov/inn  naraoraphs 
describe  the  seven  basic  SNVS  nodes. 

Fi  1 e Generati  on 

The  File  Generation  mode  provides  the  necessary  tools  and  conf igurati on 
management  aids  for  maintenance  of  all  files  associated  witn  tne  development, 
test,  and  verification  of  the  DAIS  software.  An  extensive  cataloging  syste  . 
is  maintained  for  a nutsb'^r  of  different  types  cf  software  controlled  by  5uVS 
including;  DAIS  '’'ssion  software,  SDVS  test  case  files  (defining  simulation 
scer'rios  and  data  collection  neq:i  re!"ents ) , environment  a"d  aircraft  models, 

•r d pnst  simulation  data  reduction  and  analysis  programs.  Manipulation  of 
files  cataloged  iti  SDVS  is  provided  for  by  a number  of  conversational  commands 
(e.g.,  editing,  compiling,  printing,  etc.)  described  in  section  4. 1.2.2. 

File  Structure 

Each  file  tyne  is  cataloged  by  SDVS  on  a version/revision  basis.  For 
example,  when  the  user  creates  a mission  software  file,  it  is  cataloged  as 
version  1,  revision  0 and  stored  in  a "baseline  file".  As  the  user  edits 
the  file  in  later  sessions,  he  creates  a number  of  revisions.  Each  revision 
results  in  the  edited  changes  being  cataloged  as  a unique  record  in  the 
"difference  file"  for  the  particular  file  version.  At  any  point  in  time, 
he  can  combine  all  the  revisions  associated  with  a particular  version  and 


nnk,o  a mbv  vorsion  with  the  conversational  NLXT- VtRS  1011  coririand.  Under 
SnVS  the  user  can  access  any  version  and  revision  nui'i()or  for  a file  since 
each  CDIT  session  qenerates  a unique  entrv  in  the  difference  file  for  a 
particular  file  version,  fiqure  4-1  illustrates  this  capability. 

( 2 ) file  Conversational  formands 

SDVS  provides  the  user  a number  of  commands  to  perform  various 
actions  on  SDVS  files.  The  followinq  commands  illustrate  soiie  of  the 
functions  provided  for: 

HfLP  - List  the  format  of  all  SDVS  user  commands 

ACCESS  - Make  available  a specific  file,  versiot  , revision 

for  processing 

EDIT  - Perform  text  editing  on  a file 

COMPILE  - Compile  a J73  program 

COPY  - Copy  a file  onto  another  file  name 

UEXT-VERSIOfl  - Generate  a nev/  version  from  all  the  revisions  of 
the  version  specified 

PRIOT  - Print  a file  on  the  system  hard  copy  device 

CREATE  - Create  a new  file 

EllTE'l  - Enter  a file  from  the  host  computer  into  the  SDVS 

catalogs 

OUTPUT  - Output  a file  from  SDVS  to  the  host  computer 

In  internreting  the  above  commands,  SDVS  will  interrogate  the  Con- 
fiquration  Management  cataloas  to  determine  if  the  user  has  authority  to 
access  the  desired  file  (file  security  is  specified  in  the  Supervisor 
Mode,  section  4,1.7).  If  he  does  not,  he  is  output  an  error  message  and 
asked  what  else  he  wants  to  do;  otherv/ise  the  requested  operation  is 
performed. 

For  example,  if  the  user  desires  to  compile  version  5,  revision  2 
of  the  file,  NAVIGATION,  he  would  enter  the  following: 

COMPILE  NAVIGATI0N/5/2/MSW 

where  MSW  indicates  a mission  software  file  type  requiring  the  JOVIAL 
compiler.  SDVS  will  assemble  a single  text  file  from  the  difference 
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FIlENAME-NAV 


filfi  and  basoline  file  stored  in  the  catalons  (see  Tinure  1 ) and  call 
the  system  JOVIAL  compiler.  Upon  completion  of  tlie  compilation,  the 
compiler  will  retorn  control  to  SDVS  which  will  now  automatically  link 
the  translated  code  to  version  5 revision  1?  of  file  fJAVIOATIOU.  Note, 
that  the  user  does  not  have  to  keep  track  of  source  file  names,  ob.iect 
file  names,  etc.;  these  functions  are  handled  automatically  by  the  SDVS. 

Tlie  followinp  naraqraphs  discuss  the  three  basic  file  types  maintained 
by  the  SDVS;  mission  software,  simulation  test  case,  and  post  run  edit 
fi les. 

( 1 ) Mission  Software  Files 

The  SDVS  catalogs  provide  configuration  control  for  the  development, 
test,  and  maintenance  of  the  DAIS  mission  software.  The  user  will  have  the 
capability  to  create  and  edit  JOVIAL  code  and  C0I1P00L  data  files.  SDVS 
will  automatically  link  COMPOOl.  data  files  to  program  files  in  the  catalogs. 

The  user  will  be  able  to  produce  listings,  save  newly  created  and 
undated  files,  and  invoke  the  JOVIAL  J73  compiler  or  the  DAIS  processor 
assembler.  The  SDVS  will  automatically  catalog  all  revisions  made  to  a 
mission  software  file,  and  catalog  object  modules  from  successful  compila- 
ti ons. 

Figure  4 is  an  example  of  an  interactive  SDVS  session  used  to 
create  a mission  software  file  (flS'J-PQT-DRI VER- 1 ) that  is  to  be  linked 
with  a COMPOOL  file.  All  user  inputs  are  outlined. 

(4)  Simulation  Test  Case  Files 

The  File  Oeneration  mode  of  SDVS  operation  also  provides  the  user 
the  capability  to  create,  modify,  and  translate  source  test  case  files 
containing  Simulation  Control  Language  statements.  These  source  test 
case  files  provide  the  directives  which  define  the  initialization  and 
control  of  a simulation  run  including  sequences  of  operations,  failure 
conditions,  outputs  to  the  rough  output  tape  for  post  processing  in  the 
Post  Run  Edit  Mode,  etc. 

The  user  inputs  to  build  test  case  files  are  of  two  types.  Conversa- 
tional Language  and  Simulation  Control  Languaoe.  The  user  will  enter  Con- 
versational Languane  commands  to  enter  the  appropriate  file  handling  'node 
of  operation,  i.e.,  create,  edit,  print,  copy,  etc.  The  test  case  files. 
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snvs  IS  KiADY.  WHir.ti  Monr  oi  opi  rai ion, is  di sirid? 

n j’l  Oj 

YOU  ARP  NOW  PNlIklNG  HIP  GINLRAIIQN  I'.OOL  OF  OPl.R/\l  ION 
WHAl  ACM  ON  DO  YOU  U/iJJT  10  PI  RI ORM? 

INIIR  ''HH  P"  10  I IS!  IHP  AVAllABIP  COMrANDS 

IMIR  "HHP  J^CmMAND  r.'AML"  10  OPT  IHP  SYNIAX  OF  A GIVPN  COK'-AND, 
t ) ijcRt  Aj_P  j;KW-l-QT-  DRI  VI  R J 
HI  L'IY'PI>PSW1 
SI  CURl  lY  I I VFl  J 

MSI  FO.'iPOOL  MIPS,  ONP  AF  A IIMP,  USING  OIL  lOMOWING  I OWAT 
II  IIOVIP/VI  RSION/RPVISION 
II  lOlINAIP  IHP  I 1ST  W1  IH  A 
:isw  UlP-OI/A/r] 

< M #J 

(Note:  rO.'lPOnP  f i 1 f'S  f.iust  alrcddy  pxist  and  he  conpiled) 

MSI  LOPY  MHS,  ONP  AT  A IIMP,  USING  IHP  lOIIOWING  1 OWAT 
I II  PNA’IL/VI  RSION/Rl  VISION 
IIRHINAIP  IHP  1 1ST  W]  Tfi  A "j?". 

COPY  til  os) 

{Note;  COPY  filos  must  already  exist, to  Ge  specified) 


»**  INURING  It  CO  CRIAIP  SISSION  --  SIART  WIIH’!'; 

*■1  ICOMPOOL  ’MSW-CMP-Ol'  (l.MPSRT)*] 
i’ROC  ORIVIR; 

Bf  GIN 
NUM  = A; 

IIMtS  [1]  = 4; 
lIMtS  [21  = 49; 

IIMtSfO]  = 19; 

IIMIS[4J  = 14; 

SORIPG; 

I IMf  S fll  = 49; 

IIMfS[2]  = 17; 

I I MIS [3]  = 11; 

1 IMIS  (41  = 19; 

SORIPG; 

I ND; 
l5Sj 


RMURNING  I ROM  HUT  SISSION  OR  J/3 

VIRSION  1 01  IHIS  IMP  HAS  HI  I N CRIAIID  AND  lOCKPD  10  IHIS  lISFR. 
l.'HAl  AC  1 1 ON  DO  YOU  WAN  I 10  PIRIORM? 

1 1 OGOI  rj 


Figure  ^ Pxample  of  Creating  a File  in  SDVS 
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tlipnselvos,  v/ill  contain  statenonts  in  tho  Sii'Ujlation  Control  Lanquaqo 
which  are,  at  user  request,  translated  to  an  internal  forni  for  later  use 
in  'iirectim  a Sinulation  run. 

The  orinarv  output  of  buildinq  test  case  files  are  the  internal  test 
case  files  which  will  be  used  to  control  the  in i tial i zat ion  and  execution 
of  sinulation  runs.  In  addition,  the  user  will  obtain  interactive  outouts 
durino  file  nani  nula  tion , such  as  successful  conoletion  and  ri^ror  messaqes. 

The  test  case  directives  file  will  reference  mission  suftware  files 
that  are  to  be  used  in  the  sinulation.  It  will  provide  directives  to 
oenerate  the  rouqh  output  tape  which  will  he  analyzed  after  the  sinulation 
run  is  complete.  The  test  case  directives  source  and  internal  files  are 
maintained  in  the  SHVS  file  cataloos.  Section  4 Do.  (1)  presents  an  example 
of  a Simulation  Control  l.anquane  proqram. 

( S ) Post  Run  Fdi t Files 

The  File  Generation  mode  of  STlVS  operation  also  provides  the  user  the 
capability  to  create,  modify  and  translate  source  Post  Run  Edit  directives 
files  to  internal  form.  These  PRE  directives  files  contain  the  Data  Pro- 
cessinq  Lannuaqe  commands  which  define  the  processino  to  be  done  on  a 
rouoh  output  tape  in  the  SDVS  Post  Run  Editor  mode  of  operation. 

The  user  inputs  are  of  two  types,  Conversati onal  Lanquaqe  and  Data 
Processino  Lanquaoe.  The  user  will  enter  Conversational  Lanquaqe  Commands 
to  select  the  desired  file  handlinq  node  of  operation,  i.e.,  create,  edit, 
print,  copy,  etc.  The  PRE  directives  files,  will  contain  statements  in 
tlie  Data  Processino  Lanquaqe,  which  at  user  request,  are  translated  to  an 
internal  form  for  input  to  the  Post  Run  Editor.  A sample  PRE  proqram  is 
presented  in  section  4 No.  (1). 

The  primary  output  of  this  mode  of  operation  are  the  internal  PRE 
directives  files  which  are  used  in  the  Post  Run  Editor  SDVS  node  to  perform 
data  editinq  functions  on  a particular  rouoh  output  tape  qeneratcd  by  a 
sinulation  run.  In  addition,  the  user  will  obtain  interactive  outputs, 
sucli  as  successful  completion  and  error  messaqes,  durinq  the  file  manipula- 
tion and  translation  process.  The  PRE  directives  files,  source  and  internal 
are  cataloqed  by  SDVS.  A PRE  directives  file  may  be  specified  by  the  user 
in  a test  case  file  to  be  automatically  run  at  the  end  of  a simulation  run. 
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c . S et  Up  and  Run  S i niul  ation 

This  rx)dp  of  onoration  is  used  to  submit  a simulation  run  based 
on  a test  case  directives  file  that  has  nreviously  been  created  and 
translated.  The  user  inputs  for  this  node  of  operation  include: 

0 Specification  of  the  test  case  file 

0 flaximum  simulation  tiiae 

0 Tine  of  day  for  executing  the  simulation 

SDVS  will  automatical ly : 

0 Retrieve  the  test  case  file  and  load  the  specified 
mission  software  for  simulation 

0 Interact  with  the  machine  operator  to  mount  the 
necessary  tapes 

0 Perform  initialization  commands  specified  in  the 
user's  test  case 

0 Execute  the  desired  simulation  scenario 

0 If  specified  in  the  test  case,  automatical ly  transfer 
control  to  the  Post  Run  Edit  node  and  perform  post  run 
data  analysis  and  editing  on  the  simulation  data. 

The  software  tools  used  for  simulation  of  a DAIS  mission  are  described 
in  section  3. 

d . Post  Run  Edit 

The  Post  Run  Edit  node  provides  the  user  with  the  ability  to  analyze 
the  data  recorded  on  a Rough  Outnut  Tape  during  a simulation  run.  The  Post 
Run  Editor  v/ill  access  the  user-specified  translated  f^ost  Run  Edit  directives 
file.  The  directives  will  specify  what  data  is  to  be  selected  from  the  ROT, 
what  analysis  is  to  be  run  on  that  data,  what  format  is  to  be  used  to  display 
the  analysis  results,  what  user  routines  are  to  be  used,  and  what  devices 
are  to  receive  the  output  files  created  by  the  Post  Run  Editor. 

The  Post  Run  Editor  provides  tabular  printouts,  interactive  displays 
and  data  plots  based  on  user  directives.  An  important  feature  is  the  ability 
for  a user  to  write  an  analysis  routine  in  JOVIAL  and  have  it  execute  within 
the  framework  of  the  Post  Run  Editor. 
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e.  Rollback 


Tho  rollback  function  will  nrovide  the  user  tlio  capability  to 
rosta''t  and  rerun  an  SDVS  simulator  ‘‘"oni  a point  durinq  a previous 
sinulation  run  as  stored  on  a sn.  'pe.  The  user  nay  chanoe  the 

test  case  to  obtain  additional  o'.'  . ' alter  eyistinq  conditions, 

followinq  the  point  saved  on  the  S'- •■sh'':  c tape.  The  user  will  do  this 
by  qeneratinq  a Rollback  test  case  file  whiclt  will  tie  nerqed  with  the 
one  used  for  the  earlier  sinulation  by  SDVS. 

The  user  will  input  a specification  of  the  Rollback  test  case  file 
to  be  used  and  the  original  Test  Case  file. 

The  outouts  of  this  node  of  operation  will  be  a sinulation  run  wtiich 
(if  no  chames  were  nade  in  the  test  case  file)  will  exactly  natch  tho 
previous  one.  Channes  nay  be  nade  to  provide  further  analysis  of  a sinula- 
tion run  which  is  of  special  interact. 

f.  Delete  Mode 

This  node  of  operation  is  only  available  to  the  SDVS  manager  and  provice 
hin  the  capability  to  delete  files  from  the  various  SDVS  catalons.  This 
function  was  nade  a manager  level  function  to  allow  manager  level  control 
over  the  disposition  of  all  files. 

d-  Supervisor  Mode 

This  node,  like  the  Delete  node,  is  available  only  to  the  SDVS 
nanaoer  for  confi guration  control  purposes.  One  of  the  features  of  the 
SDVS  file  management  scheme  is  that  before  a user  may  generate  any  file  in 
File  Generation  more,  sneci fi cati ons  must  have  been  created  for  that  file, 
including  the  provision  of  a list  of  users  who  are  authorized  to  write 
(e.n.,  create  new  versions)  on  the  file  and,  if  appropri ate, a list  of  users 
who  are  free  only  to  read  it.  The  creation  of  file  sneci fi cations  must  be 
perfomed  from  Sunervisor  node.  This  node  can  be  entered  only  by  a SDVS 
user  logged  in  on  the  special  Manager  programmer  number. 


In  Sun(?rvisor  mrlp,  stat.ennnts  in  thn  Conversational  Lanquaqe  v/ill 
be  entered.  One  of  these  statements  will  allow  the  manager  to  create 
snecifications  for  a particular  file,  and  enter  the  initial  list  of  users 
who  have  authority  to  read  and/or  write  that  file.  Another  statement 
allies  the  manager  to  charuie  the  autliority  of  a user  from  read  only  to 
read/write  or  vice  versa,  or  add  new  users  to  the  list  of  authorized  users, 
or  remove  users  from  the  list.  Both  of  these  commands  may  be  completely 
soecified  by  the  user  or  he  may  elect  to  be  partially  or  entirely  prompted 
for  the  necessary  information. 

There  is  onlv  one  type  of  output  to  the  authorized  user  from  Super- 
visor mode.  This  outout  consists  of  information  relayed  to  the  user  about 
the  >'es'jlt  of  processinn  his  request.  This  mioht  be  a description  of  any 
syntax  «rror  which  has  beer?  detected  by  SHVS  or  an  indication  that  an  error 
occurred  while  the  request  was  being  processed,  or  a message  indicating 
that  the  request  was  satisfied.  The  specification  files  and  the  lists  of 
authorized  users  are  inaccessible  to  any  SDVS  user  whether  in  Supervisor 
mode  or  not.  Finure  4-3  illustrates  the  use  of  this  mode. 

2.  SDVS  User  Languages 

In  the  File  Ceneration  SDVS  mode,  the  user  can  create  simulation 
test  case  and  nost  run  edit  files.  These  files  are  user  programs  written 
in  the  SDVS  Simulation  Control  Lanouaqe  (SCL)  and  Data  Processing  Language 
(DPL).  The  Simulation  Control  Language  provides  the  mechanism  for  the 
user  to  control  a simulation  by  specifying  initial  conditions,  scheduling 
events  to  occur  based  on  time  or  conditions,  and  specifying  output  to  bo 
generated.  The  Data  "recessing  Language  is  used  to  specify  the  output  data 
and  format  desired  (hardcopy  printout,  tenninal  display  or  Plot). 

a . Simulation  Control  Language 

The  SDVS  Simulation  Control  Language  is  a programming  language  used 
to  specify  simulated  DAIS  missions.  The  language  syntax  is  patterned  after 
the  JOVIAL  language  and  can  bo  categorized  into  (1)  non-executable  statements. 
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Figure  b Example  of  Supervisor  mode  operation 
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{?.)  s(?qiiential  s tatenents , and  (3)  asynchronous  staterionts.  The  non- 
executable statements  are  used  to  convey  control  information  to  the 
simulation  system  such  as 

0 the  mission  software  to  he  simulated 
0 the  fliqht  profile  tape  to  be  used 

0 the  Post  Run  fdit  proqram  to  be  executed  after  the  simulation 
0 the  variables  to  be  traced 
0 the  tyoe  of  computer  simulation  (ICS  or  SLS) 

0 the  type  of  rollback  (and  tit'ie) 

Certain  sequentially  executed  statements  provide  many  of  the  capabilities 
of  conventional  proqramminq  lanquaqos  such  as  FORTRAN,  PL-1,  and  JOVIAL. 
Other  sequential  statements  direct  the  Simulation  Control  Proqram  to  per- 
form a simulation-related  function.  These  statements  are  used  to: 

0 ass  inn  values  to  variables 
0 transfer  control  to  other  statements 

0 evaluate  a loqical  expression  and  execute  one  of  two  state- 
ments depending  on  the  value  of  the  expression 

0 activate  simulated  computers 

0 collect  data 

0 turn  traces  on  and  off 

0 terminate  the  simulation 

Asynchronous  statements  are  not  executed  sequentially,  they  are  executed 
asynchronously  as  the  result  of  a user-specified  condition  becoming  true. 
In  a sense,  the  true  state  of  the  condition  behaves  as  a software  interrupt 
which  triqgers  the  execution  of  the  statement.  There  are  three  types  of 
conditional  statements  providing  different  types  of  asynchronous  control: 

0 The  WIIFN  statement  contains  a condition  and  a sub-statement. 

The  first  time  the  condition  becomes  true,  the  sub-statement 
is  executed.  An  Fnqlish  language  analogy  is  "When  Harry  gets 
home  ask  him  to  go  to  the  grocery  store".  The  first  time 
Harry  gets  home  he  is  asked  to  go  to  the  store;  he  is  not 
asked  every  time  he  gets  home. 
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0 Th“  !!HCMr.Vi;R  statenont  also  contains  a condition  and  a snb- 
statonont.  Cvorvtino  the  (.ondition  bocones  true,  the  suli- 
statenent  is  executed.  An  analnov  is  "'Ilionever  the  car  runs 
1 f>;  on  qas,  till  it  up".  T!ie  car  qets  filled  uo  evervtii'’e  it 
runs  low  on  nas.. 

o The  WHll.r  statement  contains  a condition,  a renetition 
frequency  ami  the  hane  of  an  SCI.  nrocedure.  Until  tlie 
condition  becones  false  the  SCL  nrocedure  is  nerforned 
repeatedly  at  that  specified  rate.  The  old  sayinq  "Keen 
doinq  it  lintil  you  qet  it  riqht"  niqht  be  inplemented  usinq 
a WHILE  statement. 

( 1 ) SCL  Exampl e 

To  illustrate  use  of  the  SCL  in  testina  mission  software,  consider  the 
develonnent  of  a new  navipation  alqorithm,  WAV,  that  has  been  created  and 
comniled  in  the  SPVS  mission  software  file  cataloos.  The  user  is  interested 
in  qeneratino  a fliqht  profile  such  that  the  SDVS  avionic  and  sensor  models 
will  qenerate  realistic  naviqation  sensor  data  for  innut  to  the  WAV  routine. 

Fiqure  6 is  a pictorial  representation  of  the  following  fliqht 
scenari o: 

0 Takeoff  is  atlatitude  35^,  longitude  117^  with  a thrust  command 
of  12000  pounds. 

0 When  the  X velocity  x 170  f ps , pitch  the  aircraft  at  2^/second. 

0 When  the  pitch  angle  > 20°,  maintain  that  pitcli. 

0 '''hen  altitude  exceeds  10000  feet,  level  the  aircraft  by  settinq 
a neqative  pitch  rate, 

0 When  the  pitch  angle  is  less  than  zero,  terminate  the  simula- 
tion. 

Using  tfie  SOVS  SCL,  the  user  builds  a test  case  file  to  specify: 

0 The  flight  nrofile. 

0 Oata  to  be  recorded  for  post  processinq. 

0 Sensor  data  to  be  used  by  the  WAV  routine. 
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Fiqure  7 is  an  SCL  pro(jrdn  for  this  example.  The  reader  should 
note  the  followim  points  in  this  sample  proqran: 

0 The  CnhFiriURE  statement  specifies  the  STANDALOiJE  node 

which  allo/s  a user  to  interface  directly  with  environment 
model  data  via  an  EFS  (Executive  Functional  Simulation) 
block  instead  of  usinq  the  real  DAIS  executive  software. 

It  also  specifies  the  SDVS  simulator  (the  SLS)  and  the 
files  to  be  loaded  (version  1 revision  0 of  ’lAV). 

0 The  EFS  Control  Block  ( EFS-NAV- INPUT)  defi’nes  the  assign- 
ment of  environment  node  sensor  data  (denoted  by  the 
prefix  E:)  to  variables  in  th«^  proqram,  NAV.  These 
assignment  statements  will  be  executed  periodically  at  32 
times  per  second  prior  to  executinq  the  UAV  routine  as  de- 
fined by  the  statement, 

PERFORM  EFS-riAV-iriPUT  EVERY  .03125  UflTIL  1000;. 

0 The  IhCEUDE  statement  allov'S  the  user  to  copy  in  other 
test  case  files  to  be  included  as  nart  of  the  test  case. 

0 The  ROT-SIM-DATA  block  defines  model  and  mission  software 
position  data  that  is  to  be  recorded  once  a second  as 
defined  by  the  statement, 

PERFORM  ROT-SIM-DATA  EVERY  1 UNTIL  1000;. 

0 The  CON-INIT  block  defines  all  the  initial  conditions  at 
ground  zero.  These  assignments  are  executed  by  the 
statement , 

PERFORM  CON-INIT;. 

p*^  0 The  statements  defining  the  mission  profile  correspond 

to  the  flight  profile  illustrated  in  Figure  4-4. 
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Figure  7 Sample  SDVS  SCL  Program 


f . Hata  Process  inn  I . nqiiagr  ( 

A SnVS  siniilatinn  npnpratos  3 vilurtp  Hal.a  cnllpctpd  at 
n'in(?rnus  points  in  a sinnlation.  th  thp  SCI.,  thp  usnr  can  snpcitv 
bote  conditional  and  unconditional  pvonts  that  result  in  the  output 
data  to  a Counh  Outnut  Tapp.  This  tape  contaitis  all  tho  sirulator 
trace  outputs,  a load  i”ap  of  the  nission  software  for  each  llAIS  orocessor, 
run  tine  error  and  warninn  nessanes  fron  the  various  sinulators,  data 
f>^ori  the  environnent  Models  and  mission  software  defined  t)y  the  user, 
etc.,  as  they  occur  in  simulated  tine.  Finure  7 illustrates  the  use 
of  a Rough  Output  Tane  (ROT)  tjlock  defining  the  variables  to  be  recoroeo. 
P'/ery  second  during  a simulation.  From  the  vast  volume  of  data,  the  user 
must  be  able  to  sort  out  and  display  the  information  in  a meaningful  for  o'.. 

The  SDVS  Data  Processing  Language  has  been  designed  to  provide  the 
SDVS  user  an  easy  to  use  flexible  tool  to  select  for  analysis,  printout 
or  plotting  the  specific  parameter  data  he  desires.  In  selecting  data 
to  be  outDut,  the  user  does  not  have  to  worry  about  conversion  of  mission 
software  or  environment  model  data  from  binary  to  the  correct  output  fornat, 
this  is  all  handled  automatically  by  SDVS.  To  determine  the  correct  formats, 
SDVS  reads  the  symbol  tables  generated  for  mission  s:^tnre  and  environment 
model  programs  by  the  JOVIAL  and  FORTRAN  comoilers,  and  extracts  tho  necessar 
information.  This  SDVS  tool  removes  much  of  the  drudgery  sometimes 
associated  with  data  analysis.  The  DPL  provides  the  following  user  oriented 
functions : 

0 Ooneratinn  and  editing  of  data  files  containing  user 
defined  variables  from  the  ROT. 

0 A PRINT  capability  to  output  generated  data  files  to 
the  printer. 

0 A niSPLAv  capability  to  output  information  to  the  user's 
interactive  terminal. 

0 A statistical  nackage  to  compute  statistical  information 
of  simulation  data. 
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0 Automatic  •jonoration  of  plots  oased  on  collected  simulation 
data . 

0 Lxecution  of  user  supnlied  analysis  routines  using  a 
simulation  HOT. 

^ ^ OPI-  Example 

Finuro  8 is  a DPL  program  tliat  can  he  used  to  nrocess  data 
collected  in  the  SCI.  example  shown  in  Figure  7. 

This  PPL  orogran  is  used  to  print  out  the  environmental  model  and 
mission  softv/are  nav  data.  This  data  will  he  printed  on  the  line  printer, 
and  will  he  analysed  hy  a user  routine,  error  analysis,  to  determine  the 
mission  software  error.  This  error  is  then  plotted  as  a function  of  time. 

The  reader  should  note  the  following  noints  from  this  sample 
orogran; 

0 The  rOflFIfiURr  statement  specifies  the  user  routine  to 
he  executed,  and  its  language  (JOVIAL). 

0 The  OII'IFPATF  statement  is  used  to  create  a data  file, 

‘lAV-PATA,  which  includes  all  the  data  on  the  ROT  block, 
ROT-Sin-PATA. 

0 The  FORMAT  statement  is  used  to  define  the  format  of 
the  data  file  (flAV-ACCORACY ) which  is  computed  by  the 
user's  routine. 

0 The  PRINT  statement  will  automatically  print  out  all  the 
data  contained  in  the  data  file,  NAV-DATA,  The  output  is 
in  a tabular  format  and  is  tine  tapped, 

0 The  PLOT  commands  shown  allow  the  user  to  specify  the  plot 
title,  the  axis  titles,  and  any  desired  data  conversions. 

The  user  could  also  specify  the  X and  Y axis  lenpths,  the 
minimum  and  maximum  X and  Y values  allowed,  and  any  biases 
to  be  added  or  subtracted  from  variables  to  ho  plotted. 
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•IMI5  PfiST-iir.’-fnii  IS  u:in  to  r»Kn  out  nif 

■|Nv;t,OVUNIAl  fTOSl  A'.D  UiSSlO:.  SOMW/Mf  f.AV  OATA  IROM" 

•A  SniJlAIIOT  M'-i.  THIS  TATA  RUL  Of  .’RIGTID  O’l  II. L IIN[" 
■IRIMTIR.  ANO  Will  rr  A'.AiY.’l"  BY  A ll'.!R  ROUT  IN!,  i PROR' 
•AS.VYSIS,  10  cn;'':ui.:  IHI  MISSK':;  SOII-AR:  (ru-.r.  tU!S" 
•(RROR  IS  Itiil.  PL0IT;0  ,\S  a PURCriJS  Of  liRI" 

•SPlCUr  THE  OSER  ‘RROR-A:iA; ''SIS  OOUIIUE' 

CdVfl&URE  USER-ROlOINE  JOVIAL  E PROA- AViALYSl  S/ ./O; 

■CfNIRATE  llir  OATA  Flit.  *;AV-DATA.  CORTAIHIUG” 

■THE  PARAr.tlERS  IN  ROI  BIOCP,  ROT-S  llt-DAIA. " 

GIWP.Mf  UAV-DATA  ROT-S  lit- DATA; 

•nrfiur  tue  eata  fiu  containing  tae  ouip'/i  of  the  user" 

■ROUTINE.  IHIS  OUTPUT  IS  THf  lAViu/MION  f RROR  FOR  lATlTUOE 
•LONGITUDE,  AITITUUE,  .V.'O  THE  SlUHATION  TKIl,  Ill'E" 

lOWlAI  NAV-ACCURACV 
BEGIN 

FLOATING:  LAT-EPR, 

ElOATING:  lON-EPR, 
llOATIt.G:  AIT-LRR, 

FLOATING:  TIME 
END; 

•PRINT  OLH  ALL  THE  FLS'F  AND  EFS  NA'/  DATA^ 

PRINT  NAV-DATA; 

"EXECUTE  THE  USER  POUTINE,  E RROR- ANAL  YS  IS . WHICH  COMPinES^ 
•IHE  NAVIGATION  ERROR" 

■IIIPLrr  EILf:  NAV-DATA^ 

•OUTPUT  FILE:  NAV-ACCURACV 

EXECUTE  ERROR-ANAL  FSIS 

NAV-E)AIA:NAV-ACCURACY; 

•PLOT  THE  COMPUTED  IvAVLC.ATlOll  ERROPS  AS  A PUNCTIOl  Of  TIME 

plot  HAV-ACCURACY  SIM-TI  U.  LAT-PRR(RAn-DEG) 

TllLE-'LAllIUDE  ERROR  VS  liMi' 
XLAMLE''TIME(SEC)' 

YLFJIlf -'LATI  HIDE  ERROR'DIG!'; 

PLOT  NAV-ACCLIRACY  SlIVTIME.  1 ON- f RR(  RAO- DEG) 

TIUE'LONGIIUOE  EPR'JR  VS.  TIME' 
XEANLE-'llMI  (SIC)' 

YLABLE-'LO'IGIlUDi  ERROR  (DIG)'; 

PLOT  NAV  ACCURACY  SiM-TIME,  AIT-EFR 

TlIir-'Al  TIIUOL  IRROP  VS.  TIME' 
XtAT:tE-'UML(SEC)' 

TLWUE-'ALinuDL  E I!ROR(  E I ET  ) ' ; 


Figure  H Sample  SDVS  OPL  Program 
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SDVS  Siniildtinn  Facilities 


Section  4,  c.  described  the  SDVS  Set  Nn  and  Run  Siiaul  ation  Mode 
in  which  a user  specifies  a test  rase  file  defininn  the  desired  sinulation 
scenario.  Section  4,  a.  presented  an  introduction  into  the  test  case 
lannuaoe  used  to  describe  sinulation  scenarios.  The  numose  of  this  section 
is  to  present  the  SPVS  sinulation  tools  that  sinulate  the  DAIS  hardware 
(nrocessors,  data  bus,  remote  terminals)  shown  in  the  rinht  half  of  Figure 
2 and  provide  analooous  "sunnort"  capabilities  shown  in  the  left  half 
of  the  sane  fioure. 

Finure  9 presents  the  DAIS  Intenrated  Test  Red  Facility  from  a SDVS 
simulation  point  of  view. 

The  left  half  of  Finure  9 illustrates  the  SDVS  suooort  facilities  for 
mission  software  testinn  and  validation  functions.  The  heart  of  this 
support  facility  is  the  Simulation  Monitor  and  fontrol  function.  It  can 
b(?  viewed  bv  tho  user  as  a "virtual  machine"  oerforninn  functions  of  the 
f’erformance  Monitor  and  Control  and  Simulated  Subsystems  Data  Formatter 
computers  of  the  DAIS  siipnort  facility.  The  virtual  SDVS  machine  is 
actually  much  more  po'^'erful  than  the  actual  computers  since  there  are  no 
hardware  1 i'"itations,  and  all  monitorinq  and  control  functions  can  occur 
in  ;:ero  simulation  time. 

Tho  riqht  half  of  Finure  9 shows  the  SDVS  simulators  of  the  DAIS 
components.  The  only  simulator  not  included  in  the  current  version  of 
SDVS  are  for  the  DAIS  Controls  and  Displays  which  may  be  added  at  a 
f'jti.re  date.  The  SDVS  code  execiitors  consist  of  both  a Statement  l.evel 
Simulator  (SLS)  and  an  Interpretive  Computer  Simulator  (ICS).  The  SLS 
executes  mission  softv/are  qenerated  by  the  D73  compiler  for  execution  on 
the  host  DEC  10,  while  the  ICS  executes  the  actual  DAIS  processor  code  with 
bit  level  accuracy.  Since  the  SLS  actually  executes  on  the  DECIO.  the 
throuqhput  is  very  hinh  compared  to  the  interpretive  execution  of  the  ICS. 
These  two  tools  provide  the  user  a choice  of  fidelity  in  the  simulation 
of  mission  software  code. 
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a.  SnVS  Support  facillU' 

Tho  SnvS  Siinport  Facility  consists  of  a nui'it'er  of  tools  that  SDVS 
uses  to  innlenent  the  sir-ulation  scenario  defined  in  the  user's  test  case 
file.  The  Sinulation  Monitor  and  viontrol  function  interprets  the  user's 
t^'anslated  Sinulation  Control  Lamuane  test  case  and  nerfori'S  the  necessary 
functions.  The  translated  test  case  essentially  consists  of  a number  of 
tables  and  instructions  defininn  data  to  be  collected,  nonitorinn  of 
conditional  events,  user  run  tine  control  of  sinulation  events,  execution 
0^  the  environment  models,  etc. 

( 1 ) Code  Fxe cu tj2_r  1. i nker/Loaders 

Since  SDVS  can  simulate  both  HHCIO  and  DAIS  processor  code,  it  must 
be  able  to  link  and  load  both  tynes  of  object  code.  In  addition  to  load- 
inq  object  code  the  1 inker/loaders  also  process  snecial  tables  nenerated 
by  the  >173  mission  softv/are  compiler  for  SDVS  use.  These  tables  include 
the  statement  boundaries  for  each  JOVIAL  statement  and  a list  of  the 
variables  that  can  be  set  by  each  .lOVIAL  statement.  The  statement  boundary 
information  enables  SDVS  to  trace  mission  software  execution  at  the  JOVIAL 
statement  level.  The  list  of  variables  set  for  each  statement  is  used  to 
set  uo  the  nionitorinq  facilities  for  evaluation  conditional  events  (e.n.. 
Simulation  Control  Lannuaqe  'iHF'!,  WHE'ILVFR,  and  MtllLE  statei’ients ) . 

( 2 ) Snapshot/Rol  1 hack 

The  Sinulation  Control  Lanquaqe  includes  a SNAPSHOT  statement  which, 
when  executed  durinn  the  course  of  a sinulation,  results  in  saving  the 
state  of  the  mission  software,  the  code  executors,  the  data  bus  model,  and 
the  environment  models.  A snapshot  can  be  nerforned  based  on  a conditional 
event  (e.n.,  HMEN  A>  50  OR  R < 30  THEN  PERFORM  SNAPSHOT),  or  at  periodic 
intervals  as  defined  in  the  Simulation  Control  Lanquaqe. 

Tlte  user  can  later  initiate  a rollback  via  the  SDVS  Rollback  (TOde 
to  any  simulation  snapshot  point  and  restart  the  simulation  from  that 
point.  In  restarting  a simulation,  the  user  can  modify  his  tost  case 
files  to  delete  or  add  new  conditions  to  bo  evaluated,  re-ini ti al ize 
mission  software  and  environment  model  data,  and  add  or  delete  SCL  control 
blocks  (subroutines). 
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TI)o  usp.  of  this  tool  cdii  save  many  hours  of  DfClO  conputor  time 
hv  not  havinq  to  start  sinulation  runs  from  tirie  /.pro  to  qet  more  de- 
iviuninn  infornation.  or  to  analyze  perfornanco  by  chanqinq  critical 
ya>'iahl(’b  in  the  mission  softv;aro  or  environment  models. 

l-i)  P>eco*~di no 

'^nVS  can  record  a wealtli  of  information  to  assist  the  user  in 
tli«'  debuqijinq  or  validation  of  mission  software.  The  data  that  can  be 
recorded  diirinq  a simulation  i’^cludes  the  followino: 

fa)  Code  executor  trace  information  (statement  trace,  t”ansfer 
trace,  ICS  renister  trace,  ICS  instruction  trace,  etc.). 

(b)  Data  bus  simulation  trace  information  (I/O  interrupts 
qenerated,  bus  commands,  bus  traffic,  etc.). 

(c)  Environment  model  trace  information  defininn  the  time 
each  model  was  executed. 

(d)  Values  of  variables  selected  to  be  traced  by  the  user  eacii 
time  they  are  updated. 

(e)  Simulation  run  time  warninq  or  error  messaoes  detected  by 

snvs. 

(f)  User  defined  mission  software  or  environment  model  data  as 
requested  by  the  user. 

As  described  in  section  4.2.2. 1,  the  user  cati  analyze  data  collected 
b>'  a simulation  by  constructinn  a proqram  in  the  SDVS  Data  Processing 
Lanquaqe. 

(4)  Subsystems  Data  Formatting 

Since  SDVS  uses  the  same  environment  models  that  will  be  used  on 
tite  actual  facility,  the  Subsystems  Data  Formatting  function  is  very 
similar  for  both  SDVS  simulations  and  DAIS  facility.  The  only  difference 
is  that  for  SDVS,  this  function  interfaces  with  the  sinulation  of  the 
remote  terminals  included  as  part  of  the  data  bus  simulation.  As  the 
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■'ission  software  exerutive  initiates  1 /D  roriniands  whidi  address  variables 
cnnnuted  bv  the  environnent  riodels,  this  ^unction  will  siqnal  tlie  Sinula- 
tion  Monitoi  and  Control  function  to  pass  data  to,  or  receive  data  fropi 
a :'odel,  and  if  necessary,  execute  the  annronriate  node!  at  that  instant 
of  sinulation  tine.  This  technique  of  executinn  environment  nodels  on 
demand  insures  accurate  sensor  data  for  the  mission  software. 

(b)  iiiriulated  Real  Tine  Clock  and  Run  Time  Control 

These  two  functions  orovide  ttie  sequencinq  of  sinulation  events 
which  drive  the  Siniilation  Monitor  and  Control  function.  The  simulated 
clod,  alonq  with  several  event  queues  provide  the  ability  to  simulate  in  SDVS 
all  the  parallel  operations  that  occur  sinul taneous ly  on  the  real  DAIS 
facility.  The  narallel  operations  include  the  operation  of  multiple 
nrocessors  and  multiple  BCIUs. 

Run  tine  control  includes  the  queuino  of  events  for  data  recordinq, 
execution  of  environment  nodels,  sinulation  of  transmission  delays  over 
the  data  bus,  evaluation  of  conditional  events,  and  performance  of  Simula- 
tion Control  Lanquane  "subroutines".  This  function  provides  control  of  a 
Master  Cvent  Table  which  disnatches  the  events  described  above  for  execu- 
tion. 

f . SnvS  Simulators 

The  SDVS  simulators  of  the  actual  DAIS  hardi/are  nrovide.user  tools 
to  debuq  and  validate  HAIS  mission  software  in  conjunction  with,  or  to 
the  exclusion  of,  the  actual  DAIS  hardvare.  The  code  executors  and  data 
bus  sinulation  each  contain  a small  interface  for  communication  with  the 
Simulation  Control  and  fionitor  function.  This  interface  provides  data  to 
the  simulators  to  indicate  simulation  of  error  conditions  (bad  parity  on 
the  bus,  invalid  bus  protocol , etc.)  and  receives  data  from  the  simulators 
to  be  loaned  by  the  Data  Recordinq  function.  This  interface  is  well 
defined  and  documented  such  that  it  would  be  possible  to  substitute  a 
different  ICS  for  a new  DAIS  processor,  or  a different  Data  Dus  simulation 
for  a different  multinlex  protocol.  This  ability  to  substitute  SDVS 
simulators  is  also  possible  because  thn  SDVS  Support  Facility  shown  in 
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rinuro  h,  and  tho  Sinulation  ('.ontrol  and  Data  Procossinq  languaqos  have 
bopn  dpsiqnpd  to  bn  as  indpppndpnt  as  pnssihlp  from  tlip  simulators.  This 
canabilitv  to  siibstitutP  simulators  opons  un  a wholp  nov/  v/orld  of  ootpntial 
SnvS  annl  ications.  As  much  as  DAIS  is  to  bp  used  to  evaluate  and  study  nev. 
avionic  hardware  and  software  concepts,  SDVS  could  be  used  as  an  enqineer- 
ina  facility  to  evaluate  the  DAIS  concept  with  different  processor  cap- 
abilities, data  bus  protocol,  etc.  Since  the  Sinulation  Control  Lanquanp 
test  case  pronrans  and  Data  Processinn  Lanquaqp  post  nrocessino  nroorans 
are  independent  of  the  simulators,  a number  o^  standardized  oroorams  in 
these  lanquaqes  can  be  developed  to  evaluate  different  nixes  of  the  DAIS 
simulators  and  conoare  their  relative  nerfornance. 

(1)  Internretive  Computer  Simulator  (ICS) 

The  ICS  provides  a bit  level  simulation  of  the  DAIS  processor  to 
support  the  testinq  and  validation  of  mission  software..  The  ICS  will 
simulate  the  operation  of  the  DAIS  processor  at  the  instruction  level, 
such  that  the  resultino  contents  of  reqisters  and  memory  after  execution 
is  the  same  as  the  results  obtained  on  the  actual  processor.  The  ICS 
also  simulates  the  input/outnut  operations  of  the  processor,  the  interrupt 
system,  all  addressable  registers  in  the  CPU,  and  all  the  processor  memory. 
SDVS  can  simulate  multiple  iC.Ss  communicating  over  the  data  bus. 

( 2 ) Statement  Level  Simulator  (SIS) 

The  SLS  allows  the  mission  software  desiqner  to  check  out  his  equa- 
tions and  Program  design  without  beinn  concerned  with  the  details  of 
implementation  on  the  DAIS  processor.  The  SLS  executes  DECIO  code  and 
will  run  many  times  faster  than  the  ICS,  thus  allowing  faster  testing  of 
the  software  design. 

The  SLS  runs  on  the  DTCIO  computer  and  executes  JOVIAL  source  state- 
ments in  nCClO  code.  The  JOVIAL  compiler  provides  tlie  code  to  be  executed 
by  the  SLS,  alono  with  traps  to  indicate  JOVIAl.  statement  boundaries.  The 
SLS  may  be  thouoht  of  as  a code  processor  similar  to  the  ICS,  but  at  a 


hiqher  Ipvol.  Thp  ICS  executes  one  instruction  at  a time,  the  CLS 
executes  one  .lOVIAL  source  statement  at  a time.  Ilultiple  SLSs  may 
run  concurrently  in  the  SDVS. 

( 3 ) Pata  Bus  Simulation 

The  SDVS  Data  Bus  Simulation  is  a tool  that  functionally  simulates 
the  DAIS  multiplexed  data  bus  architecture:  It  v/ill  simulate  the  command/ 

resDonsG  characteristics  of  the  data  bus  with  respect  to  I/O  requests  by 
the  SDVS  code  executors  (ICS  and  SLS),  and  the  transmission  of  data  to/fror 
the  vtiCious  modeled  sensors.  The  bus  si  ir,,. ; ■'ti  on  will  model  the  various 
components  of  the  data  bus  such  that  the  interface  presented  to  the  ICS  or 
SLS  is  the  same  that  would  be  presented  to  the  actual  DAIS  processors. 

The  simulation  was  desiqned  to  be  independent  of  the  DAIS  executive 
and  I/O  control  software.  This  is  done  by  i nterpreti vely  simulatinq  the 
BCIU  reqisters;  the  response  of  the  simulation  to  requests  from  tlie  code 
executors  is  based  on  the  state  of  the  simulated  reqisters.  'Hie  bus 
simulation  also  provides  the  Simulation  Ilonitor  and  Control  function 
"event  profiles"  which  define  the  time  sequenced  events  commensurate  with 
a bus  operation  (e.q.,  master  BCII)  commandinq  a remote  BCIU  to  receive 
data).  "Event  profiles"  are  also  constructed  to  simulate  the  events 
associated  with  error  conditions  that  can  occur  in  the  real  world.  Ths 
user  can  specify  the  occurrence  of  simulated  errors  in  SCL  test  case  proqram. 


r.ici  ION  V 


nrsiGN  AND  iMPiLfirriTAiioN  TrcimiQUf.s 


I . Top-Davn  Ajiprnach^ 

The  purpose  of  this  section  is  to  describe  TPy's  approach  to  the 
development  of  the  5DVS  software  and  to  comment  on  some  of  the  techniques 
employed.  The  nasic  desiqn  philosophy  was  based  on  a top-down  approach 
to  software  design,  development,  and  test.  Top-down  design,  as  applied  to 
the  SDVS  software  development  includes  tiie  tcllowing  techniqiies  whicti  are 
discussed  in  detail  in  tiie  following  sections; 

0 Overall  design  of  the  program  hierarchy  and  successive  refinenents 
of  ttiis  design  from  software  requirements  to  specifications.  A 
basic  design  criteria  was  to  develop  the  SDVS  to  be  re-hosted 
on  another  large  scale  system  with  minimal  modifications. 

0 Definition  of  all_  control  and  data  interfaces  according  to  the 
hierarchy.  Standard  "Interface  Diagrams"  are  used  to  convey 
tnis  information  to  all  project  members. 

0 establishment  of  programming  standards  defining  the  tools  and 
rules  to  be  used  for  software  development.  This  includes  use 
of  structured  programming  tediniques  and  a high  level  language 
which  supports  the  structured  pt'og ramming  conventions. 

0 Integration  and  testing  according  to  a three  phase  delivery 

schedule  in  which  each  phase  provided  enhanced  SDVS  capaoi 1 i ties . 
Fonnal  testing  procedures  were  based  on  testing  the  functional 
requirements  reflected  in  the  program  hierarchy.  Testing  included 
developing  tests  that  followed  the  successive  refinement  process 
involved  in  the  basic  design  in  addition  to  standalone  testing  of 
various  functions. 

0 Configuration  control  procedures  for  both  the  development  and 
testing  of  the  software.  During  development,  procedures  were 
used  for  controlling  data  shared  among  programs  and  utility 
functions.  During  tes ting, stri ct  configuration  control  of  all 
files  was  enforced  and  a formal  problem  reporting  system  was 
employed. 
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As  can  be  seen  from  the  overview  of  the  above  techniques,  the  TRW  aqoroach 
to  top-down  design  incorporated  a number  of  new  techniques  in  software 
technology  being  advocated  in  the  literature  today.  TRW's  approach  for 
the  SDVS  software  development  was  to  integrate  these  new  techniques  into 
an  overall  systems  approach  to  develop  a top-down  strategy  for  tiie  design 
development,  and  testing  of  the  5UVS. 

The  following  paragraphs  describe  in  more  detail  the  top-down 
techniques  used  in  the  SDVS  development.  Since  many  of  these  techniques 
are  relatively  new  and  little  data  is  available  on  the  advantages  and  dis- 
advantages of  their  aoplication,  an  evaluation  of  their  use  for  SDVS  will  be 
presented. 
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i5.  Hict'tiixnial  Df’sion 

Thp  (josiqn  of  tho  SDVS  v^is  I'asod  on  the  ()rnqran  hierarchy  shov/n  in 
i rinqre  5-1.  f'ach  box  shown,  except  for  the  qroupinq  of  DI'CIO  services, 

j represents  a deliverable  SHVS  proqran.  The  following  paraqranhs  briefly 

' describe  the  hiorarchial  oroan i xa t i on  shown.  This  section  concludes  with 

some  conslijjions  concerninq  experience  riained  during  iinnlenentation  of 
the  program  nierarchv. 

(1)  Pmqran  tli_G^rjirchj[^ 

SnvS  Control  Program 

This  i)ro(jran  interacts  with  the  user  in  determining  the  desired  mode 
of  operation  and  then  transfers  control  to  the  appropriate  second  level 
routine.  All  host  processor  functions  are  performed  by  this  program  (I/O 
handling,  calling  the  systf'-i  compiler,  etc.)  based  on  conversational 
commands  innut  by  the  user  from  the  File  'Teneration  mode  and  from  second- 
level  program  requests.  It  will  also  submit  simulation  runs  into  the  batch 
system. 

Software  llana_2e:  .ent  Prmj^rari  (SflP) 

Tliis  programwill  maintain,  and  provide  controlled  access  to.  all 
SDVS  files.  It  will  provide  the  capability  to  store,  retrieve,  interrogate 
and  protect  these  fi’es  by  building  and  maintaining  ^ile  catalogs  containing 
infonnation  about  the  files.  Examples  of  such  information  are  user  file 
name,  internal  file  name,  file  type,  program  version  number  and  revision 
number,  creation  date,  security  lock,  and  author. 

I'o  effectively  mar^ipulate  the  File  Management  data  base,  this  program 
perfonns  tnree  major  processing  tasks,  as  follows: 

* « 0 File  Retrieval  - Whenever  a file  from  ttie  File  Management  data 

base  is  required  by  one  of  the  SDVS  programs,  the  SMP  will  be 
' invoked  to  retrieve  the  file  via  the  SDVS  Control  Program.  It 

will  use  the  retrieval  data  uspplied  to  it  to  interrogate  its 
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fil''  Cdtalons  and  locate  the  internal  nane  of  the  requested 
file.  This  internal  narie  will  he  passed  to  the  SIIVS  CP, 
which  will  use  it  to  actiially  locate  and  retrieve  the  file 
iron  secondary  storaqe. 

0 File  Disnosition  - When  a new  file  is  created  hy  an  SDV5 
proqrap  or  a user,  it  nust  be  olaced  in  the  File  Manaqenent 
data  base  under  control  of  the  SUP.  The  prooram  which 
oenerates  the  file  (e.q..  Scenario  Generator,  Simulation 
Control,  etc)  will  issue  a file  creation  request.  This 
request  will  contain  the  qualified  name  under  which  the  file 
is  to  be  controlled,  the  file  type,  and  the  name  of  the 
person  responsible  for  the  file.  The  request  will  be  passed 
to  the  SMb  where  the  data  contained  in  the  request  will  be 
used  to  create  a new  cataloq  entry  for  the  file.  The  cataloqed 
file  will  then  be  written  to  secondary  storaqe  by  the  SDVS  CP. 

0 File  Protection  - The  third  major  function  of  the  SMP  will  he 
to  provide  security  locks  on  the  files  such  that  a qiven  file 
can  only  be  accessed  by  someone  possessinq  the  natchinq  security 
key.  Each  proqranmer  will  have  security  protection  over  his 
^iles  until  his  software  has  been  completely  tested  and  is 
readv  to  become  part  of  the  official  system.  However,  the 
project  manaoerwill  always  have  access  to  all  files  in  the  data 
base. 

File  Generato r 

This  prooram  nmcesses  fil^  manipulation  commands  input  by  the  user. 
Section  4,  (2)  discusses  these  conversational  comands. 

The  File  Generator  will  not  actually  perform  these  functions  itself 
(e.q.,  COUPILC,  EDIT,  ACCESS,  etc.),  but  rather  will  pass  the  user's  requests 
to  the  SnVS  Control  Proqram  which  will  in  turn  pass  them  to  the  DECIO 
monitor  and/or  the  Software  llanaqement  Proqram. 
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Scenario  Tienerator  (SCO) 

This  pronran  is  diviiled  into  two  pronran  translators,  a Simulation 
Control  l.anquaqe  (SCI.)  translator  and  a Data  Procession  l.anquaqe  (DPI) 
translator.  The  SCL  defines  the  user's  simulation  scpnario  to  be 
executed;  the  PPL  defines  the  data  nrocessinq  to  he  performed  on  simula- 
tion data.  The  SCC  is  executed  by  a con versational  command  to  translate 
either  a SCL  or  DPL  file.  The  Scenario  fienerator  wi 1 1 retrieve  the  de- 
sired file  from  the  SMP  catalons,  translate  the  source  code,  and  cataloq 
the  translated  test  case  in  the  SMP  cataloqs. 

Simulation  Control  - Snap^^hot/Rol lhack 

These  proqrams  are  used  to  sequence  a simulation  scenario  defined 
by  a translated  SCL  proqram.  They  will  initialize  the  necessary  simulator's 
(ICS,  SLS,  data  bus,  environment)  for  execution,  load  the  users  mission 
softf/are  to  be  tested,  perform  rollbacks,  and  execute  a simulation  by 
invokino  the  various  simulators. 

Simulators  (ICS,  SLS,  Data  Dus,  CCS) 

The  nroqrams  simulate  the  DAIS  hardware.  Each  of  these  proqrams 
simulate  app*-opriate  events  (e.q.,  execution  of  an  instruction,  a tius 
transmission)  unon  direction  of  the  Simulation  Control  Proqram. 

(y)  Evaluation  of  Using  Hierarchial  Design 

The  top-down  design  process  involved  designing  the  proqrams  at  the 
nighest  level  in  the  hierarchy  first.  Based  on  this  design,  the  interfaces 
to  the  next  lower  level  of  programs  would  be  defined.  These  interfaces 
would  be  used  to  drive  the  design  of  the  next  level  of  programs  in  ttie 
hierarchy.  This  procedure  would  proceed  down  to  the  lowest  level.  Data 
and  control  oaths  between  program  elements  on  the  same  level  must  pass 
througii  a higher  progran  element  which  is  comnon  to  both.  No  lateral 
cofnmuni cations  are  allowed.  One  important  aspect  of  too-down  design  is  tiiat 
interfaces  are  based  uron  the  requirements  of  the  higher  level  program  and 
that  the  lower  level  programs  are  designed  to  fit  these  interfaces. 
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Tho  S[1VS  Control  and  Softv/are  Mananenent  Proorains,  thounh  shown  at 
the  ton  of  the  hierarchy,  are  actually  a collection  of  utility  routines 
ttiat  are  used  by  all  the  second  level  oroqrans.  The  exception  is  the 
snvs  Control  Proqran  function  that  interacts  with  tfie  user  and  selects 
tlie  node  of  oneration.  The  hierarchy  diaoran,  as  drawn,  represents  a 
functional  orqanization  and  not  the  exact  control  interfaces  between  the 
various  oroqrans.  To  have  inplenented  this  structure  in  a strictly  top- 
down  nanner  where  control  and  data  interfaces  reflect  the  hierarchy 
diaqranwould  be  impractical. 

Rased  on  this  hierarchy  diaoran,  the  control  and  data  interfaces 
between  the  SDVS  proqrans  first  developed  during  the  desiqn  of  the  SDVS 
CP  provided  a qood  first  ciit.  Once  the  desiqn  of  the  second  level  proqrans 
beqan  these  interfaces  had  to  be  nodified  to  acconnodate  newlv  defined 
functions.  The  interfaces  had  to  again  be  nodified  when  the  third  level 
proqrans  were  being  designed  in  detail.  So,  we  found  that  design  of  the 
o»'Oorar  hierarchy  is  an  interactive  process  going  in  a top-down,  botton- 
un  cycle.  Avoidance  of  this  cycle  is  practically  impossible,  by  spending 
the  ti’-'e  to  [lake  the  orioinal  interfaces  more  complete  and  more  general, 
however,  the  necessity  for  changes  is  reduced  and  much  less  modification 
of  code  must  be  performed.  Only  after  several  top-down,  botton-up  cycles 
can  a final  "top-dov;n"  hierarchy  diagram  be  drawn. 

b . Rehostibi  1 i t^v 

One  of  the  basic  SilVS  design  goals  was  that  SDVS  should  be  structured 
to  facilitate  rehosting  on  another  system.  This  was  done  by  isolating  all 
host  processo'^  dependent  software  in  the  SDVS  Control  Program  (e.g.,  I/O 
handling,  core  control,  text  editor  and  conniler  interfaces,  etc.).  Tlie 
Control  Pronran  woiild  therefore  be  the  only  program  requiring  assembly 
language  code;  all  other  programs  would  be  coded  entirely  in  JOVIAL  to 
facilitate  rehosting. 
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This  apnrocict)  wnrkf'd  out  c'xtronr.’ly  well.  Hie  only  ddditioridl 
orofjrrtn  rcquii’ina  risser;hly  lanquaqe  code  was  in  the  Sl.S  which  invol;ed 
interfacinq  with  the  JOVIAl  object  i,ode.  The  S!)VS  Control  rrocjr.im, 
ori'iinally  estirated  to  be  (,od(>d  hO,  in  assenbly  Idurjaaqe,  ro(]ui  red 
less  than  10  of  the  codinq  to  be  in  .issoiibly  lanciuaqe.  The  foTlov/inq 
n-iraqraphs  address  sone  of  the  major  tashs  of  rehosting  the  SDVS. 

Data  Strijctur(}^S 

Specified  Tables  were  used  throuqhout  all  SDVS  proqrans.  In  fact 
these  tables  represent  a machine  dependency  since  actual  bit  locations 
within  a word  are  referenced.  In  rehostinq  SDVS  to  a new  computer  many 
of  these  tables  would  have  to  he  changed.  This  would  irwolve  extensive, 
but  straiobtforv/ard  modification  of  data  declarations  only.  The  actual 
code  which  processes  these  tables  would  remain  unchanged. 

SDVS  ConU'ol  Prnqrj^m 

As  Dreviously  mentioned,  all  machine  dependent  code  was  incorporated 
into  the  desion  of  this  program,  A major  concern  in  reftosting  will  be 
the  investigation  of  available  techniques  for  interacting  with  a new  host 
roni tor/operatinq  system.  There  are  rajor  Control  Program  techniques  for 
interfacing  with  the  DECIO  monitor  v/hich  are  probably  realized  differently 
on  other  processors.  These  include: 

0 Use  of  pseudo  teletypes 

0 Paging  swapping  considerations 

0 Pile  directory  operations 

0 Account-code  schemes 

0 Tape  Moiinting  Utilities 

0 Interfacing  wi th  sys tern  processors  (editors,  compilers) 

0 I/O  schemes 

0 Special  compiler  and  text  editor  interfaces 

So_ftjw^re  11ana£erient  Program  (SMP) 

The  SDVS  SfTP  is  implemented  with  the  DF.C  Data  Base  Management  System 
(DR11S)  software  developed  in  COBOL.  Rehosting  this  program  requires  an 
Information  Management  System  package  that  would  provide  for  the  same 
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interfaces  as  DEC'S  DBMS.  Questions  that  nust  be  ansv/ered  include 

0 Is  it  a "standalone"  systeri  or  callable  froni  other 
proqrans  (e.o.,  SDVS)? 

0 Ha-;  sinilar  are  its  cataloging  facilities  to  those 
of  DBMS? 


0 How  sinilar  are  its  operators  and  calling  sequences 
to  those  of  DBMS? 


0 Is  it  COBOL  hosted? 
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I,.  Control  and  Data  Interfaces 

As  mentioned  above,  the  control  interfaces  in  SDVS  v/ere  comoletely 
defined  by  the  hierarchy  structure.  A program  could  be  called  only  by  a 
orogram  of  a higher  loi/el  and  in  turn  it  can  only  call  programs  of  tne  next 
lower  level.  Programs  of  the  same  level  have  no  direct  interface.  A 
controlling  orogram  of  the  next  higher  level  must  pass  any  necessary  infor- 
mation exchange  between  two  programs  of  tiie  same  level.  After  following 
this  approach  completely  at  the  start  of  SDVS,  the  need  for  a set  of  corir^ion 
utility  routines  (I/O,  parser,  conversion,  etc.)  available  to  all  programs 
soon  oecame  obvious.  However  this  was  the  only  major  diversion  from  the 
hierarchy  defined  control  structure. 

All  DlCIO  services  (Action  Processors)  in  SDVS  are  requested  via  Control 
Points.  A Control  Point  is  a data  area  wi  tii  enough  fields  to  describe  any 
available  service.  For  example,  one  field  contains  a code  for  the  type  of 
service,  another  contains  the  address  of  a buffer  area  (used  on  I/O  requests 
only),  etc.  .Vhen  a program  requests  a particular  service,  it  fills  only 
those  fields  in  the  Control  Point  pertaining  to  tnat  service.  The  use  of 
Control  Points  provides  one  data  area  for  the  passing  of  information.  In 
SDVS  one  Control  Point  was  used  for  passing  information  to  the  action  orocessor 
and  another  for  returning  results  to  the  calling  program.  Thus  all  data  input 
to  the  Action  Processor  remained  intact  even  after  the  action  had  been 
serviced.  This  has  proved  very  beneficial  in  debugging  the  logic  of  programs 
requesting  DECIO  services  and  in  decreasing  the  complexity  of  data  manipulation 
in  the  Control  Program  itself.  Insofar  as  meaningful  names  are  assigned  to 
the  various  Control  Point  fields,  they  are  very  self-documenting  and  make  it 
very  easy  for  a programmer  to  incorporate  calls  on  new  Action  Processors. 
Unfortunately,  in  SDVS,  as  the  number  of  Action  Processors  expanded,  several 
^ Control  Point  fields  took  on  duplicate  unrelated  meanings  in  calls  on  different 

Action  Processors.  This  ambiguity  made  the  Control  Points  harder  to  use  and 
introduced  greater  possibility  of  errors. 

Each  SDVS  Action  Processor  was  described  on  an  Interface  Diagram  which 
listed  the  Control  Point  fields  needed  by  the  Action  Processor  on  input  and 
described  the  meanings  of  eadi  possible  completion  code  or  output  generated 
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fron  thf?  service  request.  These  diagrams  provided  a dear  description 
of  the  interfaces  required  for  a given  service  request  and  a central 
definition  point  to  facilitate  updates  and  modifications  of  these 
interfaces  (see  Figure  5-2  for  an  example). 

In  addition  to  Control  Point  interfaces  most  SDVS  programs, 
esnecially  in  the  simulation  system,  need  to  share  several  data  items 
with  their  controllinn  orogram.  These  data  interfaces  were  controlled 
by  reguirino  all  data  common  to  two  programs  to  reside  in  a separate 
comoool.  One  copy  of  this  compool  was  kept  so  that  changes  to  the 
interface  were  immediately  reflected  in  both  programs.  Figure  12 
shows  the  connool  interface  between  the  SCP  and  EES  programs. 
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Sottv/riff?  nev<?l  opi''Pnt  St.andariis 


Tin's  section  describes  the  SDVS  software  development  standards  for 
develnprient  of  the  SRVS.  The  standards  were  predicated  on  the  use  of 

structured  programi.iinq  techniques  and  a high  order  language  tliat  suonorts 
tliese  techniques. 

( 1 ) Structured  Prngranini no 

Structured  prngranninn  is  based  on  the  nathenati cal ly  proven 
Structure  Tfieorem  wh  i ch  states  that  any  proper  program  (a  program  with 
one  entrv  and  one  exit)  is  equivalent  to  a nronran  that  contains  as 
Ionic  structures  only: 

0 sequences  ot  two  or  more  operations 

0 conditional  branch  to  one  of  two  operations  and 
return  (IF  a THTM  b F.LSF  c) 

0 repetition  of  an  operation  while  a condition  is  true 

(no  UHILF) 

Fach  of  the  three  structures  itse'*f  represents  a proper  program.  Us  inn 
combinations  of  these  basic  structures,  any  program  can  be  built.  Fven 
though  any  program  can  be  built  with  those  basic  structures,  it  is  desir- 
able to  include  additional  structures  which  provide  more  readable  and  ^clf 
documenting  pronra’-^s,  more  efficient  programming,  and  programmer  conveniences 

As  a tool  to  aid  in  designing  the  SDVS  software  using  a set  of  program- 
ming constructs,  structured  flowcharts  were  lised.  These  flavcharts  are 
ditferent  than  conventional  flavcharts  in  that  each  programming  structure 
has  a unique  flowchart  representation.  The  programmer  builds  bis  program 
by  combining  the  basic  structures  in  constructing  a program.  The  flowcharts 
simplify  the  arrangement  of  program  logic  to  a process  like  that  used  in 
engineering  where  Ionic  circuits  are  constructed  from  a basic  set  of  Ionic 
functions. 

(,))  snVS  Structured  Prograiami n^ Juans tr^Js 

The  structured  programming  techniques  employed  included  the  definition 
of  six  basic  structures  (IF,  WHIl.F,  FOR,  I F-TUFU-FLSE , IF-AUY-1,  and  CASE) 
and  standards  defining  the  J73/I  language  constructs  to  be  used  for  each 
structure.  Two  additional  structures  were  added  to  accommodate  situations 


v/hpre  the  six  basic  structures  v/ouid  tie  inefficient  and  v/ould  lead  to 
softv/are  that  v;ould  contain  unnecessary  Ionic  and  therefore  iie  harder  to 
understand,  verify,  and  maintain.  These  structures  include  an  ESCAPE 
construct  allowino  an  error  exit  from  a routine  without  havinq  to  use  a 
number  of  extra  1 F-TIIEM-ELSE  constructs  testinn  for  the  error  conditions, 
and  an  EXPANSION  construct  which  provides  the  proaramer  a strictly 
controlled  GO-TO  capability  to  execute  looical  functions  without  havim 
to  use  subroutine  calls. 

Fiqure  ^ illustrates  the  flow  chart  standards  and  JOVIAL  J73/I 
source  code  for  each  control  structure. 

( b ) Eval uation  of  Stru ctured  Programming 

Use  of  structured  programming  techniques  proved  to  be  an  extremely 
beneficial  in  the  development  of  the  SDVS  software.  Cy  carefully  defining 
the  basic  structures  to  be  used  in  the  context  of  the  J73/I  language, 
structured  orograming  facilitated  the  on-schedule  development,  debugging, 
testing,  and  delivery  of  a highly  reliable  system. 

The  use  of  structured  flowcharts  is  a natural  way  to  represent  pro- 
gram logic  in  a language  independent  notation.  Originally  SDVS  was 
developed  in  JOVIAL  J70  prior  to  the  availability  of  J73/I.  During  the 
J70  development,  the  structured  flowchart  constructs  were  represented  by 
J70  syntax  instead  of  J73  as  shov/n  in  Figure  13.  The  conversion  from  J70 
to  J73  was  therefore  a "cookbook"  operation,  i.e.,  substitutino  one  srt  of 
syntactical  statements  for  another.  It  would  even  be  possible  to  write 
FORTRAN  statements  corresponding  to  each  basic  structure,  although  the 
structures  are  more  suited  to  a JOVIAL  like  lannuage.  In  other  words,  the 
flowcharts  allow  the  programmer  a way  of  representinn  the  abstractions  of 
a problem  indeoendent  of  ttie  lanouaoe  and  computer  to  be  implemented. 
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"IHent  1 


SWITCH  i; 

BEGIN 

BEGIN 

statement  1 ; 


"icient  2" 


statement  N; 

GOTO  ENDNAME; 
ENDSW 
BEGIN 

statement  1; 


"iflent  N' 


statement  N; 

GOTO  ENDNAME; 
ENDSW 


BEGIN 

statement  1; 


ENDNAME; 


statement  N; 

GOTO  ENDNAME; 
ENDSW 
END 


ESCAPE 


EXPAND  (NAME) 


13  SDVS/J73  Control  Structures 
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"SWITCH  i" 


"SWITCH  i" 
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THEN 


IIEIIH 

"THEN"  BEGIN 
statement  I; 


statement  N; 
END 

ELSE  BEGIN 

statement  1; 


statement  N; 
END 

ENDII  EIEH 


conrlltion  1 


lEE  I TH  condition  1 ; 

BEGIN 

statement  1; 


staferTicnt  N; 

END 

ORIF  condition  2; 
BEGIN 

statement  1; 


statement  N; 
END 


ORIF  NONE’OF'THE'ABOVE; 
BEGIN 

statement  1; 


statement  N; 
END 
ENDIFEITH 


Note:  In  this  example,  the  final  ORIF  condition  used  the  define  "NO NE 'OF'THE ' 
ABOVE".  This  is  to  be  used  only  if  the  final  blocks  of  code  is  meant  to 
process  any  situation  not  handled  above.  If  nothing  is  to  be  done,  if  all 
conditions  fail,  the  ORIF  NONE'OF'THE'ABOVE  block  should  be  omitted. 

13  SDVS/J73  Control  Structures  (Continued) 


E'igu  re 


IF 


condition; 

BEGIN 

statement 


statement 

END 


1; 

N; 


WHILE 

condition 


WHILE  condition; 
BEGIN 

statement  1; 


statement  N; 

END 


FOR  i : j BY  k WHILE  i LQ  m; 
BEGIN 

statement  1; 


statement  N; 

END 


where: 

i is  a variable  name. 

j,  k,  m are  arithmetic  expressions 
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Arirli  tional  advantaqps  of  usina  structured  prooranninq  include; 

0 Thp  usp  of  structured  flov/  charts  v;as  judqed  to  be  the  most 
useful  tool,  with  respect  to  structiired  prooranninq  concepts, 
for  desiqninq  softv/are.  All  of  the  proqranriers  aqreed  that  it 
provided  the  means  to  clearly  represent  the  structure  of  their 
proqrans  on  paper.  Abstract  ideas  could  tie  easily  written  down 
usinq  these  flowchartinq  technique.  It  also  proved  very  easy 
for  one  prooranner  to  study  another's  flavcharts  and  readily 
understand  then.  A1 1 of  the  prooranners  anreed  that  they  prefer 
this  techniqiie  to  tliose  of  the  past,  and  would  continue  to  use 
it  on  future  projects. 

0 Readable  source  code  that  can  eas i ly  be  cross- referenced  with 
flov/charts.  The  code  itself  was  very  self  docunentinq. 

0 Facilitates  debuqqino  in  that  pronran  structure  is  more  apparent 
and  that  there  is  only  one  entry  and  exit  point. 

0 As  a by-product,  it  somewhat  standardized  proqranninq  style 
across  the  nroject.  This  made  it  easy  for  project  nenbers 
to  work  on  proqrans  otiier  than  their  own  and  facilitated  open 
communication  anonq  proqranners  aboiit  the  desiqn  and  debugqinq 
of  one''  code.  This  open  communication  concept  is  sometimes 
referred  to  as  "Egoless  Programming"  in  the  literature. 

0 The  use  of  the  structured  flowcharts  seemed  to  automatically  en- 
force softv/are  nodularity.  The  process  of  breaking  a problem 
into  si/ccessively  simpler  parts  and  piecing  these  parts  together 
naturally  fell  out  of  usinq  these  flowchartinq  techniques. 

By  and  large,  SDVS  benefitted  from  the  use  of  structured  prooramming. 
However,  structured  programming  is  not  a cure-all  for  poor  programming 
techniques  - in  fact,  structured  proqrans  may  lead  to  worse  programs  than 
non-structured  ones  because  it  is  more  difficult  to  do  things  which 
proliably  shouldn't  be  donel 
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( 2 ) Program  M£du  l_a  r i ^ 

The  goal  nf  orogram  modularity  is  to  separate  complex  operations 
into  several  .veil  defined  functions  each  of  wliich  in  itself  can  be  declared 
to  be  "obviously  correct"  by  inspection.  To  a large  degree  this  goal  .vas 
acliieved  in  SDVS.  Modularity  requires  a more  disciplined  design  aooroach 
in  that  more  procedure  calls  are  required  and  each  procedure  must  include 
several  overhead  statements  defining  local  data  items,  etc.  This  tediousness 
and  human  nature  are  the  greatest  obstacles  to  overcome  in  producing  modular 
code  and  the  reason  that  no  large  system  is  ever  modularized  as  completely 
as  it  could  be. 

Modularization  does  introduce  some  overhead  to  a system,  out  this 
overnead  is  greatly  reduced  if  data  can  be  accessed  by  the  procedures  without 
iiaving  to  pass  parameters.  This  is  achieved  in  SDVS  by  nesting  of  procedures 
and  py  defining  data  in  compools  global  to  all  procedures  within  a given 
program.  The  second  drawback  of  modularity  is  in  error  checking.  If  an 
error  can  occur  several  orocedure  calls  deep,  each  calling  procedure  must  have 
a check  and  separate  branch  for  the  occurrence  of  that  error.  This  situation 
.vas  often  avoided  in  SDVS  by  using  the  Expansion  Block  and  Escaoe  constructs. 
This  provided  the  functional  seoaration  of  modularity  .vhile  allowing  errors 
to  escape  to  a much  higher  logical  level. 

The  true  value  of  modularity  is  the  ease  of  isolating  and  correcting 
logic  errors.  The  short  time  in  which  SDVS  was  actually  debugged  evidences 
this  benefit.  Furthermore,  the  task  of  enhancing  or  modifying  code  was 
found  to  oe  much  easier  in  the  more  modularized  areas  of  SDVS. 
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(\)  Use  of  d High  Level  Lanijuage 

.vithout  the  use  of  the  JOVIAL  language,  the  implementation  of  SDVS 
software  would  undoubtedly  have  taken  many  extra  months.  The  power  of 
using  a high  level  language  to  develoo  a system  such  as  SDVS  is  even  more 
evident  .vhen  one  considers  that  the  SDVS  development  was  burdened  with 
conversion  from  a J70  dialect  to  the  J73  dialect  had  to  use  a newly 
developed,  first  time  used  compiler,  and  still  the  SDVS  development  team 
felt  that  the  use  of  JOVIAL  was  essential  to  meeting  the  delivery  date. 

One  reason  JOVIAL  was  so  helpful  was  the  ease  with  which  it  can  be 
learned.  To  master  the  DEC  fJACRO  assembly  language  would  probably  have 
taken  much  longer  than  mastering  JOVIAL.  Just  the  reduction  in  lines  of 
code  between  a JOVIAL  and  a MACRO  implementation  of  SDVS  saved  countless 
hours  of  coding  and  debugging  time. 

The  JOVIAL  control  structures  (WHILE,  IF-ELSE  IF,  etc.)  lent  theinselves 
very  well  to  implementation  of  our  structured  flowcharts.  By  expanding  these 
strucutures  with  DEFIIlE's,  TRW  was  able  to  develop  code  templates  correspondi ng 
to  each  of  the  logical  constructs  allowed  by  the  structured  programming 
standards.  This  made  coding  from  flowcharts  extremely  straightforward. 

The  data  structures  allowed  by  JOVIAL  were  also  beneficial  to  SDVS 
development.  Compools  were  used  to  control  program  interfaces.  Processing 
of  cumbersome  data  was  eased  by  multiple  word  items  (e.g.  , long  character 
strings)  and  multiple  item  table  entries.  Specified  tables  allowed  efficient 
use  of  partial  word  items  such  as  links,  easy  implementation  of  variable 
length  table  entries,  and  overlaying  of  data  items.  These  capabilities  were 
used  to  define  and  manipulate  complex  linked  lists  and  to  develop  templates 
for  externally  defined  data  descriptions  (i.e.  Link  Item  Types,  UUO  data 
blocks,  etc.).  Processing  of  data  input  to  buffers  was  greatly  facilitated 
by  making  these  templates  based.  Specified  tables  and  the  BIT  and  BYTE 
functions  allowed  JOVIAL  code  to  perform  tasks  often  done  in  assembly  code. 

In  fact  JOVIAL  was  so  powerful  that  only  10%  instead  of  90%  of  the  SDVS 
Control  Program  nad  to  be  written  in  MACRO  code. 

Undeniably  the  use  of  JOVIAL  did  introduce  inefficiencies  and  make  the 
SDVS  system  slower.  However  TRW  feels  that  by  careful  timing  analysis  these 
bottlenecks  can  be  found  and  corrected  (by  recoding  key  routines  in  MACRO,  if 
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necessary).  Moreover  these  bottlenecks  could  not  have  been  identified  during 
the  design  phase  and  many  hours  would  have  been  wasted  developiiig  "efficient" 
and  most  likely  tricky  MACRO  code  in  routines  where  ootimization  was  not 
real ly  needed. 

Ttie  unique  JOVIAL  J73  capabilities  most  useful  in  SDVS  implementati on 
were;  the  DEFINE  strings,  specified  and  unspecified  TABLES,  BIT  and  ryTE 
manipulations,  and  COMPOOLs. 


4. 


Proaraminn  Standards 


In  addition  to  usinq  structurod  proqranninn  techniques,  there  were 
other  very  innortant  standards  that  Facilitated  the  development  process. 

The  fnllowinq  paraqranhs  hiqhliqht  some  of  these. 

I Is  e_  of  DETIf  I Strings 

Perhaos  the  most  valuable  standard  was  the  use  of  the  [)EFI’IE  capability 
in  .lOVIAL  which  allows  the  programmer  the  capability  to  substitute  one 
character  string  for  another.  The  DEFINE  feature  is  very  similar  to  the 
MACRO  feature  found  in  many  assemblers,  i.e.,  it  allows  the  proqranmer 
to  define  new  language  constructs  for  his  application. 

The  DEFINE  capability  was  used  to  greatly  simplify  the  conversion  of 
SDVS  from  JOVIAL  J70  to  J73/I.  Table  1 outlines  a list  of  SDVS  DEFINES 

which  were  contained  in  a file  used  by  all  SDVS  programs.  Note,  that  the 
defined  names  are  much  more  natural , self  documenting  descrintions  than 
either  the  J70  or  J73/I  syntax.  In  converting  from  J70  to  J73/I  this 
DEFINE  file  was  modified  to  reflect  the  change  in  language  syntax.  Note, 
also,  that  if  SDVS  is  rehosted  on  a machine  with  a 32  bit  word  size,  only 
the  DEFINES  snecifying  word  size  must  be  changed  instead  of  every  item 
declaration  apnearinn  in  the  source  code. 

The  DEFINE  feature  was  also  used  to  create  the  ESCAPE  and  EXPAND 
structured  nrogranming  constructs  shown  in  Figure  13  . Note,  from 
Table  1 that  the  use  of  a DEFINE  provides  a controlled  use  of  the  COTO 
statement  for  the  EXPAND  macro. 

Interprogran  Data 

A fundamental  SDVS  nrogrannii ng  standard  was  that  there  was  to  be 
only  one  COMPOOL  between  any  tv/o  programs  for  the  nurposes  of  sharing  data. 
The  hierarchy  shown  in  Figure  10  was  the  basis  for  defining  the  sharing 
of  inter-program  data.  Organizing  shared  data  this  way  proved  beneficial 
during  testing  in  that  there  were  only  very  minor  nroblems  found  with 
resoect  to  SDVS  shared  data  interfaces.  Usually,  testing  uncovers  a 
nlethora  of  data  interface  problems. 
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J70  PJ  LFJRENp^ 

DLI  INF 

FI  OAT 

"F"; 

Same 

DEi INE 

imi  GLR 

"S  35" 

"I  36  S" 

DLI INE 

Fill  FUORD 

"U  36" 

"I  36  S" 

DL( INE 

INDEX 

"U  18" 

"I  18  U" 

DEFINE 

ADDRESS 

"U  18" 

"I  18  U" 

Df  UNE 

FLAG 

"U  18" 

"I  18  U" 

DEE INE 

CHAR7 

"C"; 

Same 

DEFINE 

OCTAL(A) 

"3B1A" 

"A"' 

9 

DEFINE 

PRESET 

M _ « , 

» 

MpM 

DEFINE 

ENDSW 

"END"; 

Same 

DEFINE 

ENDIFEITH 

II  II  , 

» 

Not  used 

DEFINE 

IFEITH 

"IF"; 

Not  used 

DEFINE 

ORIF 

"ELSE 

IP";  Not  used 

DEFINE 

NONE 'OF  'IHE 'ABOVE 

"1"; 

Not  used 

DEFINE 

EQ 

II  - II  , 
» 

Not  used 

DEFINE 

NQ 

"<>"; 

Not  used 

DEFINE 

LS 

Not  used 

DEFINE 

l-Q 

"<="; 

Not  used 

DEFINE 

GR 

Not  used 

DEFINE 

GQ 

">  = "; 

Not  used 

DEFINE 

CALL 

M M . 

» 

Not  used 

DEFINE 

ESCAPE 

"RETURN";  fiot  used 

Lien.\'r'  >•  XfA‘'ilfK">PANSIDN  NftMf")  JNVDKE  AN  EXPANSION”" 

F^EC.IN  ”"SU  IHAT  EXPANl'  ^ILl  BE  A SIMGbE  ST  A TE,ME.N  I " " 
r-oTo  IP;  ss!E:  ; 

END  ""ENO  THE  5TA1E-^EnT'" 

"”EMi  the  'lEEl'.K  STHING ; 

OEEI'E  PE'G  1 N ' FXPAnSI  UN  ( E "XPANSION  NAf.t")  " '"'EXPANSIUN  DEEINiTlON"" 
PE  TuPn;  "••SO  A HElllPN  IS  NOT  NEE'Ot.O  FOLLOWING  MAIN  PROC"" 
hE-NFn  IE; 

"”Et[)  IME.  PEEINE  SITING >""  "• 

OEEIrE  E'rjH  ' E XPANfc  U'N  ( E "Xf'A.vSION  nAmE")  " ”"EnL)  EXPANSION  PEFlNlTlON" 
?SS!E:  ”"[)E.E  A I, ABEL  TO  PREVENT  ERRORS"" 

GOTO  SS:E;  ""RElliRN  III  EXPANSION  INVOKATION"" 

E NI> 

""enc>  the  DEEJNF  STPieG >""  "; 


Table  ^ Example  of  SDVS  DEFINE  Strings 


1nq  a njia_r ds 

As  is  corii’ton  anonn  all  pronrannina  pro.jects,  a number  of  standards 
worn  do fined  deal  inn  with  the  followinn  topics: 

n 'lamina  convontinns 
0 Hata  specifications 
0 ''.allinq  sequences 
0 Proqram  annotation 

Figure  Id  is  an  example  of  a SDVS  module  which  illustrates  the 
use  of  structured  progranminq  and  good  oronram  annotation.  This  procedure 
is  nart  of  the  Simulation  Control  Lanquaqe  translator  and  is  used  to 
generate  commands  for  evaluation  of  arithmetic  expressions  during  a SDVS 
simulation.  This  routine  is  called  after  the  arithmetic  expression  has 
been  parsed  and  the  appropriate  elements  stored  in  operator  and  operand 
stacks.  It  "pops"  the  stacks  and  based  on  tlie  operator  generates  the 
necessary  commands.  The  folloviing  points  should  be  made  concerning  this 
example : 

n The  indentation  of  the  program  structures  ( I F-TIIEfl-TLSE  and 
CASE)  facilitate  the  readability  of  the  code.  The  code 
itself  is  effectively  self  documenting. 

0 The  use  of  meaningful  variable  names  and  comments  defining 
them. 

0 The  procedure  is  short  (less  than  one  page)  and  therefore  it 
is  easy  to  grasp  its  overall  function. 

0 Expansion  block  structures  are  used  for  each  of  the  ooerator 
types  (assignment,  unary,  binary).  If  error  conditions  are 
found  in  an  expansion  block,  an  ESCAPE  structure  can  be  used 
to  terminate  processing  of  this  routine  instead  of  redundant 
code  to  check  for  errors  if  subroutines  were  used. 

0 All  sequence  structures  are  delimited  by  BECin-E'IP  blocks 
which  define  the  function  performed. 
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-I 


J73  J70JM/J_FRj^NCi 


DEFINE 

El  OAT 

"F"; 

Same 

DEFINE 

INI  EGER 

"S  35" 

"I  36  S" 

DEE INE 

EDI  1 WORD 

"U  36" 

"I  36  S" 

DEFINE 

INDEX 

"U  18" 

"I  18  U" 

DEE INE 

ADORE  SS 

"U  18" 

"1  18  U" 

DE  E INE 

FI  AG 

"U  18" 

"I  18  U" 

Dl  E INE 

CHAR7 

"C"; 

Same 

D1  FINE 

OCFAL(A) 

"3B:A" 

"A"' 

1 

DEE INE 

PRESET 

M _ n . 

“ • 

II  p II 

DEI INE 

ENDSW 

"END"; 

Same 

DEFINE 

ENDIFEITH 

II  II  . 

» 

Not  used 

DEE  INE. 

I F E I FEl 

"IF"; 

Not  used 

DEE INE 

OR  IF 

"ELSE 

[P'l-  Not  used 

DEE  INE 

NONE 'OF  'IHE 'ABOVE 

"1"; 

Not  used 

DEE INE 

EQ 

II  « II  , 
> 

Not  used 

DEFINE 

NQ 

"<>"; 

Not  used 

DEFINE 

ES 

II  II  . 
< » 

Not  used 

DEFINE 

EQ 

Not  used 

DEFINE 

GR 

">"; 

Not  used 

DEFINE 

GQ 

">="; 

Not  used 

DEFINE 

CALL 

II  II  . 

• 

Not  used 

DEFINE 

ESCAPE 

"RETURN"; 

Ul-Flf.t  f- f ^ ">FaNMON  NaNK")  JNVOKE  AM  t.X  P A MS  1 ON  " " 

fipr.lM  ""5.1)  1HA7  fcXraMl'  ^ILL  bf.  a single  STaTEMEMJ"" 

f'Oi'i  ss!E;  i 

PNn  ""ir,n  thk  57aif-^h»7"" 

""I  Ml  I BE  'IM-I'.K  SlFirJG ; 

tiEFIf-F  PrGlM’FXPAr.SJUNCt  "XPANSION  NAEt")  " ""EXPANSION  DEFINITION"" 

PefuPM:  ""SO  a bfuipn  is  nOI  nefolo  following  main  ppoc"" 

begin  :E; 

" "F  f [)  I he  liF  f I r.F  SI  F 1 NG > ; 

OEFlrF  EriO  ' F XPANv'- ION  ( F "XPA.mSION  nAmE")  " ”"F,nD  expansion  PEFlNlTlON"" 
SSSIF;  ""(lEF  A lAHFL  TO  PPFVF'NT  FRROPS"" 

GOTO  SS;F;  ""PFlllPN  It)  EXF'AnSIO.N  INVOKATION"" 

F MO 

""Ff.D  IhF  DFFJMF  STPiFG >""  "; 


Table  IS  Example  of  SDVS  DEFINE  Strings 
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Fiqure  Example  of  SDVS  module 


G.  Softy/iiro  iGStinq 

DotailGd  testinn  of  software  is  crucial  to  the  deliver''  of  a useful 
syster.  Yet,  testim  is  nenerally  the  first  area  to  be  cut  back  when 
deadlines  aonroacit  too  rapidly.  To  insure  against  this,  TP.  I 'lanned  for 
thrnn  levels  of  test  nlannim  v'ith  strong  con^iquration  control  enforced 
a^ter  connletion  of  the  first  testing  phase. 

(1)  T»st  Planning 

Testing  v/as  perforned  on  SOVS  software  in  three  phases; 

0 separate  nroorans  were  tested  individually  and  then  interfaced 
with  their  contrcllinn  and  suboridinate  prograns 

0 after  a reasonable  workinn  systen  was  obtained  fron  interface 
testing.  Preliminary  Oual ification  Tests  (PQT)  were  developed 
to  test  functional  requirements 

0 a laroe  all-inclusive  Formal  Qualification  Test  (FQT)  was  then 
run  to  demonstrate  SDVS's  ability  to  run  in  a realistic 
en vi ronment. 

These  three  levels  provided  a comprehensive  and  disciplined  testinq 
approach . 

Individual  Program  Testing 

As  a program  neared  completion,  each  programmer  would  test  his  own 
nroqram.  Because  of  the  clearly  defined  program  interfaces  in  SDVS,  it 
was  often  easy  for  the  individual  programmer  to  provide  dummy  input  to 
his  program.  This  was  done  either  manually  or  in  the  case  of  complex 
structures,  via  separately  developed  test  programs.  This  allowed  testing 
of  lower  level  programs  prior  to  completion  of  their  controlling  program. 
In  addition,  when  tv/o  programs  were  being  interfaced  and  the  lower  level 
program  had  already  undergone  extensive  testing  with  dummy  inputs  it 
became  much  easier  to  pinpoint  generation  of  improper  data  by  the 
controlling  program.  This  early  bottom  up  testing  often  exercised  many 
of  the  error  handling  routines  while  correcting  oross  logical  errors. 
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POT  T es  t i n q 

Once  the  nronramers  were  satisfied  that  a sufficiently  stable 
s»sten  had  been  put  tonether,  a series  of  PQT  tests  wore  developed.  In 
SDVS  this  turned  out  to  be  a two  step  process.  SOVS  really  contains  two 
systems,  the  Interactive  Systei"  and  the  Simulation  System.  The  hiqh  level 
Interactive  System  in  which  the  user  created  files,  translated  test  cases 
etc.,  had  to  be  workinq  before  the  lov/er  level  simulations  could  be  tested. 
Thus,  POT  was  a top-doivn  process  in  which  the  Interactive  System  was  tested 
lonq  before  the  Simulation  System. 

The  nrocess  of  developinq  the  PQT  tests  was  also  ton-down  in  nature. 
The  first  step  was  to  divide  SDVS  into  8 separate  conf i nurations  (see 
fioure  ).  Then  a detailed  list  of  functional  requirements  was  drawn  up 
for  each  nroqram  in  each  confi quration.  For  a qiven  conf i uuration  these 
lists  were  combined  into  a sinqle  list  describinq  all  functions  to  be 
tested  for  that  confinuration  (see  fiqure  16  ).  Finally,  a set  of  PQT 
tests  incornoratinq  each  of  these  test  objectives  was  developed  (see  figure 
17  ).  As  each  PQT  test  was  successfully  completed  the  corresponding  test 

objective  was  checked  off  the  list.  This  process  a11ov;ed  for  detailed 
testing  with  a minimum  amount  of  overlan,  yet  the  test  results  for  each 
test  were  clearly  defined  and  easily  documented. 

FQT  Testing 

After  POT  testing  had  shown  that  each  functional  requirement  was 
working  properly,  the  FQT  test  was  used  to  show  SDVS  ability  to  operate 
in  a realistic  environment.  Qenerally  the  FQT  test  was  a large  compre- 
hensive program  developed  at  least  in  part  by  AFAL.  Thus,  it  exercised 
SDVS  in  situations  not  necessarily  covered  by  the  smaller,  more  specialized 
POT  tests.  Furthermore,  the  fact  that  the  FOT  tests  wore  developed  by 
non-TR'l  'personnel  introduced  now  oroqramminq  styles  in  the  mission  software 
or  nev/  annroaches  to  entering  and  compiling  files  which  uncovered  some 
errors  in  both  the  Interactive  and  the  Simulation  System. 
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PHASE  III  SDVS  TESTING  CONFIGURATION 


Figure 


Corio’ete  ICS 


(ONI  K.UKAIION  NO. 
4 


SOVS  I’HASF  III  rONMOURAIlON  II  SUNG 
( ONI  I C, UNA  I ION  01  M.K1IM  ION 
SIANOAIONI  SIS  SIlilllAIION 


\,iVS  I HOi.FVu'-lS  II  Sill). 

SDVSIP,  HKH  , RB,  SU>,  SIS,  11 S 


Pdije  1 


tXIIKNAI  SOI  U.'AHI  KH.'OIKI  0 (BY)  MSI  SI. Ill  1)01  t 

Mi-.sion  SofUv.iie  files  .Y/VO  to  4/? 

I'kll'AKY  IIINI.IIONS  10  HI  II  Sill). 

1.  SDVSCP-SIS  I out  <liii.it  ion  of  orror-tidp  li.inill  i nij. 

?.  S(,P  fiiri  of  .JOB  rx-iution  for  f.iftil  orrors/li  .ips . 

3.  SCP  fix!  of  JOB  -lotion  v-.ti<'n  s iiujl  <i  li  on  times  out. 

4.  SSitirtblo  ! r.K  e of  tVA-l  v.iri.ifOe  set  from  SCI.  .mil  IISW. 

5.  Piju’rftetl  <’><-(  otion  of  NSW  iiio.loles  (l  IS). 

f).  R.  iii-.iti-.i  overl.ippin<j  e><-(  otion  of  MSW  irin.ioles  (I  IS  error) 

/.  list  r.i<  e ootpot. 

R.  t1-..r  Rr-f(  r.ncible  Sl)VS  v.iridbles  (SCP,  BBC)  in  oomli  ons . 

9.  Selective  Viiridble  Trdte  (only  from  SIMf  A to  Siflf  B) 

10.  fvdlodtiiHj  (omlitions  - when  a vdri.ible  ijcls  ch.inije'l,  verify  all  of  its 
< onifi  I i '<is  net  ( tieekofl. 

11.  Variable  rr.u.e/Conrfi  t ion  evaloalion  on  dll  elimenls  of  an  drr.iy. 

1?.  As  a resoll  of  ev.iloating  a (onilition,  (b.inye  anolber  monitored  variable  and 
vet  i fy  tiidt  it  also  is  dieiked. 

' f'luve  a variable  ftoin  its  Itu.ifion  to  a ROl  block. 

14.  Set  vdloe  of  variable  f i om  SCL  (all  data  types,  multiple  words)  (setvalue 
and  initialize) 

1^-  Multiple  monitored  variables  (MSW)  <han<jed  in  one  SIS  statement. 

16.  SIS  trace(stateiicnt  trace  with  and  without  exec  call). 

17.  SIS  Trace  (Transfer  trace). 


Figure  16 
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SDVS  PHASE  ni  fONnr.URAT  ION  71  SI  IMG 
( ONI  ir.UKAI  ION  (It  SCRIP  I ION 

SIANDAI  ONE  SI  S SIMIII  Al  ION 


sOVS  1 HOl.KAMS  II  Mill. 

SOVSC.P,  MR,  HMfl  . RB.  SI  S,  IIS 


Piiye  2 


IXIIkNAI  ‘OMl.’ARI  KlgOlRIO  (BY)  II  SI  SCIII  Dill  E 

Mission  Sof f f*  fi’i-s  3/P9  lo  7/? 

Pkl/IARY  lONCIIONS  10  HI  1 1 S 1 1 0. 

IB.  Accfss  PAIIIAC  oBjr-ct  tile  from  PAI  I I AC  PPN.  Verify  file  gels  loaded  correctly 

19.  Activate  ROr  and  IIS  Mocks  from  2 performs,  deallocate  one,  see  that  correct 

one  is  dea  1 loc  a I c’d.  (One  even,  one  odd). 

?0.  Mir  Itace  output  coitectly 

?1.  Tost  IRACE,  Rl  K sc-t  correctly  at  ACIIVAIP  and  during  simulation. 

22.  One  simple  'ollhack  with  new  Ic'st  case,  verify  snapshot  time  selc'cted. 

23.  Verify  that  ROf  is  copied  cocrnctly  thru  rollhack  /coint. 

2A.  Add  Variables  (MS'W) 

?S.  VcTify  SNAPSHOf’s  lakc’n  as  rcipces  led. 

?6.  Verify  execution  of  standalone  mode  with  IIS.  Periodic  executionj  EtS  IRACE 
dalai  My  Mission  profile,  (interface  through  SCL  statements) 

Add  new  ROT  block  in  Rollhack  with  old  and  nc'w  variable. 

?R.  Verify  at  least  one  special  jump  instruction  is  included  in  MSW. 

?9.  Legal  Hlin  lra()ping  (halts  and  exec  calls) 

30.  Block  mode  exeiution 

31.  Several  PROCS  in  MSW,  test  calling  and  returns,  Trdtisrer  trace. 

3?.  DOlir  stater.ent  ending  the  simulation. 

33.  Verify  Mas  ter  Trace  Capability  {*,*)  each  applicable  type  SIMT,  VAR,  IRAN, 

NOME 

34.  Block  tiKrde  specified  across  proc  boundary  using  cpiali  Tiers 

35.  Test  default  HBC  no.  in  Trace  and  Block. 

Figure  16  (contiaued) 
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Prtcje  3 


CONnCURAnON  NO. 


SUVb  1 HASL  111  lAJ.ii  i I'Ui'.n  I 1 u,i  I.  

1 r.ONMGUIlAIlON  1)1  Sf.RlI’l  ION 


/]  S lANDAl  ONi:  SI  S SIMIII  Al  ION 


SOVS  rWK.KW-IS  II  sill). 

sovscp,  si.p,  nun  , kb,  si  s,  ns 


IXIIHNAI  SOI  IHAKi;  RlljlllHIO  (BY)  j MSI  M III  1)111  K 

Mis'jion  Sort\,Mie  files  j lo  A/2 

PRir.AKY  1 UNCI  IONS  10  Bl.  II  Ml  n. 


36.  'Ise  l.iBpIs,  stitfpiiionl  nuiiibcr'S  <inB  ol  fsel s for  tr.iC.o  or  Block. 

37.  Set  Tr  <u;o  or  Block  in  mid  s iinol<il.ion. 

38.  Verify  error  Iwindinq  for  trrico  or  Block 

A.  MO  final  / 

R.  srj>sr^ 

C.  illegal  ( liaracfer 

D;  MOM(“xislent  IIHC,  PHOC,  I ABI  I , SIMf  NO. 
r.  Set  S 11)1 01)  to  'l.'AKN'  or  MAIAL* 

39.  link  lo  .1/3  MJMtire  tooUnes,  At  AL  math  routines,  MSW  prors,  tlSW  COMPOOIS,  MSW 
Kl  P's  arrd  1)1  f's. 

AO.  Verify  load  Map  f.eneration. 

Al.  Prror  test  in  loader,  undefined  and  multiple  externals. 


■ fiqorp  )6  (continued) 
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CONFIGURATION  4 STANDALONE  SLS  ft  SCP 


FILES  TEST  OBJECTIVES 


1.  TC-POT-CON-4-1  4A5,4A6,4-4,10,12,13,15 

TESTAD-PROCEDURE/1/0 


2. 

TC-PQT-CON-4-2 

4A7,4-8 

ARITHMETIC-TEST 

"CONDITION  TEST" 

3. 

TC-PQT-CON-4-3 

4-9,28,31,32,34, 

TESTAD-PROCEDURE/2/0 
LINK- COM 
LINK-PROCEDURE 

4. 

TC-POT-CON-4-4 

4-21,35,36,37,38 

TESTAD-PROCEDURE 

"STDCOD  TESTS" 

5. 

TC-PQT-CON-4-5 

4-30 

TESTAD-PROCEDURE 

"BLOCK  MODE" 

6. 

TC-PQT-CON-4-6 

4-11 

SPARSE-DATA 

7. 

TC-PQT-CON-4-11 

4-14 

ARITHMETIC-TEST 

"ARITHMETIC  TEST' 

8. 

TC-POT-CON-4-7 

TC-PQT-CON-4-8 

TC-PQT-CON-4-9 

TC-PQT-CON-4-10 

EES-EFS-TEST 

9. 

SDVS-TEST-FILE-DIR-5/2/1 

SDVS-TEST-FILE-DIR-5/3/1 

4-5,7,16,20 

4-6 

10. 

TEST-ROLLBACK-DIR-5/ 1/LAST 

4-22,23 

11. 

SDVS-TEST-FILE-DIR-6/ 1/LAST 
PARTIAL-TEST-CASE- 1/1/0 

4-16,25,27,29,40 

12. 

SDVS-TEST-FILE-DIR-6/2/1 

4-16, 

PARTIAL-TEST-CASE- 1/2/1 


Figure 


17,18,19 
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(2)  Configuration  Control 

Dnco  tho  individual  testing  had  been  conpleted  and  PQT  testinn 
v/as  initiated,  all  snVS  nrograns  were  placed  under  configuration  control. 
All  source  files  were  copied  to  a file  area  whose  password  was  known  only 
to  the  con^i guration  control  nanager.  Whenever,  a POT  test  exhibited 
errors  in  SDVS,  the  person  running  the  test  would  subnit  a problen  report 
stating  the  test  run  and  the  observed  error  synptons.  This  problen  report 
would  be  forv/arded  to  the  appropriate  SDVS  analyst  who  would  analyze  the 
pro' len  and  complete  a software  change  authorization  form  detailing  the 
necessary  programming  modifications.  If  the  change  was  anproved  by  the 
SDVS  manager,  the  analyst  would  copy  the  affected  files  from  the  configura- 
tion control  file  area,  make  the  changes,  and  rerun  the  specific  PDT  test 
causing  the  problen.  The  conf iouration  control  manager  would  then  copy 
the  modified  pronran  back  onto  the  configuration  control  file  area  (these 
files  were  write  protected  from  all  other  file  areas)  and  rerun  a set  of 
oreviously  vmrking  PQT  tests  checking  for  side  effects  from  the  program 
change. 

This  configuration  control  did  create  some  tine  consuming  papemvork, 
but  all  inyolyed  agreed  it  was  worth  tho  effect.  It  is  somewhat  of  a 
programming  law  that  fixing  an  error  has  a hinh  probability  of  introduc- 
ing additional  errors.  These  new  error  were  usually  caught  by  the  re- 
testing procedures  and  if  not,  the  problem  reports  and  software  change 
forms  were  often  useful  in  tracking  down  errors  caught  at  a later  time 
which  had  worked  in  oreyious  PQT  tests.  In  addition,  the  configuration 
control  procedures  allowed  two  people  to  work  on  different  errors 
simultaneously  without  interference. 

When  SDVS  was  deliyered  the  problem  report/software  change  forms 
provided  a good  base  for  user  problem  reports  and  a good  discipline  for 
undating  a piece  of  softv/are  while  it  is  being  used. 
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2.  Prn_nram  Plan 
d.  Overall  Philosonhj^ 

The  pro(iran  plan  for  Uio  devol  o|)nent  and  delivery  of  SDVS  was 
h.iSf'(l  on  a tliree  phased  dovel of)i'i(.>nt  approach.  The  [ihilosophy  was  to 
provide  interin  SDVS  capahi  1 i tit's  to  permit  early  use  of  SIIVS  and  to 
facilitate  quality  assurrince  thiough  early  use.  Both  of  ttiese  objectives 
wi're  achii'ved  with  this  approach.  An  added  lienefit  v/as  the  flexiliility 
provided  by  fieint]  able  to  respond  to  user  feedback  and  changing  require- 
r-ients  in  early  phases  and  incorjjorate  necessary  changes  prior  to  the 
final  delivery.  This  flexibility  was  especially  important  for  SDVS  due 
to  the  ('volutionary  nature  of  DAIS  and  Uiercfore  SDVS.  The  early  SDVS 
vi'rsions  could  be  viewed  as  SDVS  software  prototypes.  This  insitred 
(pjality  assurance  at  an  early  date  and  provided  time  for  evaluation  of 
SDVS  capabilities  via  user  feedback. 

b.  Development  ron_£op_t 

The  developrient  of  the  SDVS  software  followed  a top-down  procedure 
according  to  the  program  hierarchy  structure  shown  in  figure ^0-  This 
approach  is  based  on  the  overall  top-down  development  techniques  described 
in  section  5,1.  The  following  paragraphs  outline  the  SDVS  programs 
developed  in  each  phase  and  summarized  in  Table  2. 

( 1 ) DV^ 

Even  tiiouyh  a working  J73  compiler  was  not  yet  available  in  August  of 
19/5,  IRd  felt  tiiat  a basic  usable  SDVS  system  would  provide  invaluable 
information  in  determining  good  final  system  requi rements  and  design.  To  meet 
tins  goal  , IRW  began  implementation  of  SDVS  in  the  JOVIAL  J70  dialect.  The 
Phase  1 SDVS  was  geared  to  providing  a basic  interactive  SDVS  capability  for 
the  user  in  the  File  Generation  mode  to  build  SDVS  files,  and  to  provide  a 
basic  simulation  capability  with  the  SLS.  Only  a basic  subset  of  test  case 
directives  was  provided  by  tlie  original  Simulation  Control  Language.  Phase  I 
involved  development  and  testing  of  SDVS  software  from  each  of  the  hierarchial 
levels  shown  in  Figure  10  , thereby  validating  the  overall  SDVS  structure  and 
demonstrating  the  feasibility  of  SDVS  as  a tool  for  development  of  DAIS 
mission  software. 
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Ph.isp  (G  Oct.  75)  Plij^.i;  i:  1..1.  It]  Phase  U'.  ' H "■u  "■) 


I OdCii  t,i  on  of  thn  SHVS  r.ont.rol  ProiiiMn  wi  (h  ‘.ho  HICIO  o|)otMfitKi 
syston  .nul  Iho  sorond  li'vol  hoft.v/.u'o  ’VoMfK'Mr'nf , '’k  tninrio  Gonorritor,  <iri() 

S ii'vilat  ion  Control  Proor  .irs  val  i do  i.nl  tho  top-do'jn  i.onLrol  ,mil  riata  int.or- 
fa(  I's  ! th('so  pro'jrans . Inti.'ot  ai  ion  of  tho  'lot tiowo  faridijonont  Pro- 

nr.in  irivolvod  a i.ritiral  inlL'rface  with  tho  Dl.C  Data  Baso  ManatiijncTit 
System  (liiil'S;  softwaro.  Inti’^rati  n<)  tliis  software  ('aidy,  valid, itod  tho 
'■'■plox  intoijration  of  'his  softwaro  with  tho  ^IIVS  and  id-ntifiod  SDVS/lJiillS 
interfaces  inefficiencies  involving  catalog  searches.  The  lead  time  gained 
on  this  type  of  problem  enabled  TRW  to  do  an  extensive  analysis  of  DBMS 
cataloging  operations  and  optimized  the  necessary  SDVS  interfaces. 

'nalysis  of  Mio  Phase  I intcrfai.os  hotwoon  tiio  translated  Sinnlation 
'’i.n'rol  language  directives  to  t.he  Siiaulalion  Control  Program  also  resulted 
in  soi'.o  re-design  of  this  interface  which  r.'>sulted  in  a more  powerful  design 
del iverod  with  tho  final  version  of  SDVS. 

In  S',  arv,  the  Phase  1 SDVS  rloi’ons tra tod  the  SDVS  concept,  validated 
the  SfiVS  ititei  faces  with  the  host  DtClO,  and  provided  feedback  on  the  de- 
sign resulted  in  an  irnroved  linal  peoduct. 

(2)  .1 1 SDVS 

Phase  II  SDVS  was  geared  toward  enhancing  SDVS  capabilities  concerning 
tlie  stru't  .-n  of  the  Software  flanagonent  Program  mission  software  files,  and 
new  File  C.-a  ration  contsands  based  on  changes  in  requirenonts  for  the  en- 
' , I ■ ission  software  devc'l opment  standards  by  SDVS. 

In  addit;  ' ■ , ti|o  sDVS  Phase  I software  was  converted  from  JOVIAL  J/0  to  J/3/1 
and  leli.'M'j  as  the  Ph.ise  I-A  SDVS. 

Orirjinally,  the  Phase  II  software  was  to  include  the  Inl.erpreti ve 
f ■ outer  S i- 'll  a ti  on , the  Data  Bus  Sinulation,  and  the  Txlernal  Tnvironnont 
Si"'ulation,  All  of  Hiese  pi'oijr'ans  were  defionilent  on  DAIS  specifications 
whifh  were  not  availatile  for  a Phase  II  delivery  and  were  rescheduled  for 
Phase  111, 
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(3)  Phdse  III  S13VS 


The  major  oDjectives  of  the  Phase  III  SDVS  ./ere  to  integrate  the 
^AIS  simulator  programs  (level  3 in  Figure  10  ) into  the  basic  SDVS 
framework  provided  in  Phase  II.  A compreiiensi ve  siuiulation  Snapshot  Roll- 
back capability  was  developed  and  tiie  second  level  Post  Run  Editor  Program 
was  also  included.  High  powered  tracing  and  inonitoring  capabilities  (WHEN, 
.v'HEHEVER,  etc.)  were  added  to  the  Simulation  Control  Program  in  response 
to  needs  demonstrated  during  usage  of  the  Phase  I and  Phase  II  systems.  This 
experience  gained  from  the  previous  systems  concerning  translating  and 
executing  simulation  scenarios  resulted  in  a very  powerful,  efficient,  and 
sophisticated  simulation  facility.  In  addition  Phase  I and  Phase  !I  usage 
allowed  TRW  to  identify  some  of  the  detrimental  impacts  of  SDVS  on  the  DECIO 
system.  Modifications  to  the  configuration  of  SDVS  on  the  machine  (multiple 
nigh  segments,  restoration  of  SDVS  low  segment,  placing  some  code  in  the  low 
segment,  etc.)  alleviated  this  impact.  This  can  be  attributed  to  the  three 
phase  development  approach  in  which  the  first  phase  demonstrates  all  the 
oasic  capapilities  and  is  used  to  evaluate  the  design  and  fine-tune  the 
system  accordinglv.  The  demonstration  of  a basic  framework  early  in  the  SuVS 
program  played  a key  role  in  the  on-time  delivery  of  a system  that  has  been 
proven  to  exceed  original  performance  requirements  and  operate  reliably. 
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3. 


Productivity  Using  SDVS  Developnent  Techni qucs 

As  described  in  section  5,1.  the  design,  development  and  testing  of  the 
SDVS  software  applied  many  state  of  the  art  software  engineering  techniques, 
i.e.,  top-down  design,  use  of  structured  programming,  etc.  Overall,  aoolication 
of  these  techniques  oroved  instrumental  in  all  phases  of  the  software  develop- 
ment process  as  discussed  in  section  5,  1. 

To  provide  a quantitative  measure  of  the  productivity  associated  with 
the  development  of  the  SDVS  software,  the  size  of  each  of  the  SDVS  programs 
shown  in  Figure  10  was  tabulated  and  is  shown  in  Table  2.  For  each  program 

the  number  of  JOVIAL  J73/I  statements  and  the  correspondi ng  size  of  the 
generated  object  code  is  presented  for  both  program  data  and  code.  The  total 
number  of  JOVIAL  statements  for  both  program  data  and  code  for  the  SDVS  soft- 
ware is  82,965.  The  total  number  of  engineering  man-montlis  over  a 24  month 
period  for  the  development  was  227  man-months.  The  engineering  effort  included 
the  following: 

0 Requirement  Definition 

0 Program  Specification  development  including  preliminary  and 
critical  design  reviews  for  each  SDVS  program. 

0 Coding 

0 Preliminary  and  formal  qualification  testing  for  the  Phase  I,  II, 
and  III  versions  of  SDVS 

0 Delivery  of  all  documentation  including  program  specifications 
(over  5000  pages  total),  user  manuals  for  each  phase,  test  result 
documents,  etc. 

0 Providing  SDVS  user  support  since  the  original  Phase  I delivery 

0 Analysis  and  fine  tuning  of  SDVS  performance 

0 One  person  as  a full  time  manager 

0 One  person  full  time  responsible  for  configuration  management  and 
testing 

The  effective  number  of  JOVIAL  statements  developed  per  man-month  is  therefore: 
82965/227  ^ 365  statements/man-month. 
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Including  AFAL  supplied  Fortran  nodels 


This  number  represents  the  develooment  rate  over  the  entire  life  of  the 
contract  and  includes  all  engineering  tasks  associated  with  the  SDVS 
develooment. 

From  Table  2,  it  can  be  seen  that  the  total  numaer  of  JOVIAL  J73/I 
executable  statements  (69605)  resulted  in  the  generation  of  157. 75K  machi ne 
instructions.  The  ratio  of  machine  instructions  to  source  statements  is 

157750  . - machine  instructions 

69605  ' ■ JOVIAL  statement 

This  expansion  rate  demonstrates  the  efficiency  of  code  generated  by 
the  J73/I  compiler  and  therefore  justifies  the  use  of  a high  level  language 
compiler  like  JOVIAL  for  software  development.  This  low  ratio  of  machine 
instructions  per  source  statement  implies  that  the  code  generated  by  the 
JOVIAL  compiler  was  as  efficient  as  if  the  coding  was  performed  in  assembly 
1 anguage. 

It  should  be  noted  that  not  all  the  SDVS  programs  (294. 25K)  are  not  core 
resident  at  any  one  time.  SDVS  employs  several  different  schemes  to  segment 
the  SDVS  functions  such  that  only  the  necessary  programs  required  are  loaded 
in  core  at  any  point  in  tine. 
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‘AC non  VI 


CONCl.U;AOri>  ANil  Kl  cojiru  niwj  ions 


Tne  Jevel')pmenl  of  the  SDVS  orovided  a ,jealti\  of  experience  relating 
to  tm?  'nerits  of  top-down  design  and  structured  programming  techniques. 
Since  these  concepts  are  relatively  new.  their  application  to  a large  scale 
software  development  project  like  SJVS  has  presented  the  opportunity  to 
evaluate  their  effectiveness  in  a real-world  situation.  The  following 
paragraphs  summarize  this  experience  and  the  main  points  of  this  report. 


iilL' .i  ll  the  SDVS 

0 SD.'S  is  an  integrated  collection  of  software  tools  to  aid  in  tne 
design,  development,  coding  and  .'alidation  of  DAIS  miS:>ion 
software. 

p SDVS  provides  the  user  a powerful  High  Level  Language  (Simulation 
Control  Language)  to  sn^^rify  mission  scenarios  and  the  recording 
of  simulation  data.  The  SDVS  Data  Processing  Language  provides 
a user  tool  to  soedfv  the  data  reduction  and  analysis  of  simulation 

ds  t d . 

0 SDVS  provides  an  autoviated  configuration  and  file  management 
system  for  controlling  mission  software,  simulation  scenario 
software,  post  run  processing  software,  and  data  generated 
py  a simulation. 

0 SDVS  software  has  proven  to  be  flexible  enough  to  accommodate 
changing  regui  rements . 

0 Although  SDVS  response  time  is  very  good  during  low  use  periods 
on  the  DtClO,  competition  with  many  interactive  jobs 
results  in  a significant  slowdown  in  response  time.  Timing 
evaluations  and  efficiency  optimizations  are  warranted. 

0 Given  that  a reasonably  compatible  JOVIAL  compiler  and  data  base 
management  system  are  availaole,  rehosting  of  SDVS  appears  viable 
due  to  the  successful  containment  of  monitor  interaction  in  only 
one  program. 
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T 00- Down  Design  a^nd  Structured  Prograimiim 

0 Too  down  Itierarchial  design  oroved  beneficial  during  initial 
design  phases  but  proved  somewhat  inadequate  during  detailed 
design.  One  should  not  be  afraid  to  modify  initial  design 
to  accommadate  imolementation  details. 

0 Structured  progt'amming  provided  a basis  for  devolooing 
sof tware 

- quickly 

- which  was  often  error  free 

in  which  errors  were  easily  corrected 

- which  was  easily  understood  oy  other 

0 Structured  flowcharts  were  lii.ed  by  everyone.  Bv  associating 
coding  constructs  with  each  flowchart  construct,  coding  from 
the  flowcharts  was  straightforward.  The  same  flowcharts  were 
used  for  both  the  J70  and  J73  versions  of  SDVS. 

0 SDVS  was  not  as  modular  as  it  should  have  oeen.  The  exoansion 
block  concept  provides  the  benefits  of  modular  procedures 
without  inflicting  the  adverse  overhead  and  error  orocessing 
side  effects . 

0 Programminn  standards  imposed  enough  similarity  in  programming 
styles  that  programmers  found  it  easy  to  familiarize  themselves 
with  programs  written  by  others.  The  conversion  from  J73  to 
J73  was  a "cookbook"  operation  due  to  the  programming  standards. 
The  control  of  interorogram  communications  resulted  in  quick  and 
easy  integration  of  the  several  main  SDVS  Oi'ogram  modules. 

0 The  standard  of  producing  completely  detailed  flowcharts  prior 
to  the  start  of  coding  each  SDVS  program  resulted  in  increased 
producti vi ty . 

0 Flexible  working  hours  wc.re  essential  to  comoletinn  the  SDVS  on 
schedule.  Use  of  the  DECIO  in  off-hours  was  often  two  to  three 
times  as  productive  as  using  the  machine  during  normal  working 
hours . 


Ll^e  ^ f a JH L i i" 

0 The  low  ratio  (?.3  to  1)  ot  assembly  lanaua'je  i fistructi ons  oer 
JOVIAL  statempnts  shows  the  viability  of  usinq  JOVIAL  to  devslon 
largo  software  systems.  The  specified  tables,  bit  and  byte 
manipulations,  and  multiole  word  i te'iis  allowed  ^lany  functions 
typically  ./rotten  in  assembly  language  to  be  implemented  in 
JOVIAL.  The  Define  capability,  nested  procedures,  and  conoools 
lead  JOVIAL  to  be  easily  used  for  structured,  self-documented 
code. 


Pnased  Devel  oorrient  and 

0 Phased  development  of  software  provides  the  flexibility  to  accommodate 
defi cienci'^s  encountered  when  using  initial  system  deliveries.  The 
program  developers  must  however  guard  against  making  gross  design 
simplifications  in  order  to  meet  delivery  dates  of  early  phases. 

These  simplifications  only  result  in  major  regrogrammi ng  efforts. 

0 Comprehensi ve  testing  and  strict  configuration  control  are  essential 
to  developing  a stable  usaole  software  system.  The  top-down 
development  of  PQT  tests  produced  such  comprehensive  testing. 
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LI  s L_Or_/\CRONIMS 


AFAl. 

Air  Force  Avionics  lai'or.Uory 

BCIU 

Bus  Conti'ol  Interface  D'nit 

CIU 

Console  liiterfane  Unit 

CMP 

COMPOOL 

CP 

Control  Point 

DAIS 

Digital  Avioni's  Infoniiation  Sy'.'em 

L'liMS 

Data  Base  Management  System 

DtClO 

DEC  System  10 

DPL 

Data  Processing  I.anguage 

biS 

External  Fnvi ronment  Simulation 

l.FS 

Executive  Functional  Simulation 

FG 

File  Generator 

FQT 

Fonnal  Qualification  Testing 

ICS 

Interpretive  Ccsputer  Simulation 

I DP 

Internal  Directives  Record 

I rB 

Integrated  Test  Bed 

J/3  or 
J73/I 

JOVIAL  Version  73  level  One 

MSW 

Mission  Software 

OFP 

Operational  Might  Program 

PMC 

Perfor, nance  Monitor  and  Control 

PQT 

Preliminary  Qualification  Testing 

PRE 

Post  Run  Editor 

ROT 

Rough  Output  Tape 

RT 

Remote  Terminal 

SCADU 

Super  Control  and  Display  Unit 

SCG 

Scenario  Generator 

SCL 

Simulation  Control  Language 

SCP 

Simulation  Control  Program 

SDVS 

Software  Design  and  Verification  System 

SDVS-CP 

SDVS  Control  Program 

SLS 

Statement  Level  Simulation 

SMP 

Software  Management  Program 

SSDF 

Simulated  Subsystems  Data  Formatter 

TECO 

Text  Editor  and  Corrector  Program 

UUO 

Undefined  User  Operator 

VCC 

Video  Control  Center 
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